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Introduction 


本 文 主要 讨论 Apache Spark 的 设计 每 实现 ， 重 点 关注 其 设计 思想 、 运 行 原理 、 实 现 架构 及 性 能 调 优 ， 附 带 讨 论 与 Hadoop 
MapReduce 在 设计 与 实现 上 的 区 别 。 不 襄 欢 将 该 文档 称 之 为 "源码 分 析 "， 因 为 本 文 的 主要 目的 不 是 去 解读 实现 代码 ， 而 是 尽 
量 有 逻辑 地 ， 从 设计 和 与 实现 原理 的 角度 ， 来 理解 job 从 产生 到 执行 完成 的 整个 过 程 ， 进 而 去 理解 整个 系统 。 


讨论 系统 的 设计 与 实现 有 很 多 方法 ， 本 文选 择 问题 驱动 的 方式 ， 一 开始 引入 问题 ， 然 后 分 问题 逐步 深入 。 从 一 个 典型 的 job 
例子 入 手 ， 逐 淅 讨论 job 生成 及 执行 过 程 中 所 需要 的 系统 功能 支持 ， 然 后 有 选择 地 深入 讨论 一 些 功 能 模块 的 设计 原理 与 实现 
方式 。 也 许 这 样 的 方式 比 一 开始 就 分 模块 讨论 更 有 主线 。 

本 文档 面向 的 是 希望 对 Spark 设计 和 与 实现 机 制 ， 以 及 大 数据 分 布 式 处 理 框 染 深 入 了 解 的 Geeks。 


因为 Spark 社区 很 活路 ， 更 新 速度 很 快 ， 本 文档 也 会 尽量 保持 同步 ， 文 档 号 的 命名 与 Spark 版 本 一 致 ， 只 是 多 了 一 位 ， 最 后 
一 位 表示 文档 的 版 本 号 。 


由 于 技术 水 平 、 实 验 条 件 、 经 验 等 限制 ， 当 前 只 讨论 Spark core standalone 版 本 中 的 核心 功能 ， 而 不 是 全 部 功能 。 诚 邀 各 位 
小 伙伴 们 加 入 进来 ， 丰 富 和 完善 文档 。 


关于 学 术 方 面 的 一 些 讨 论 可 以 参阅 相关 的 论文 以 及 Matei 的 博士 论文 ， 也 可 以 看 看 我 之 前 宇 的 这 篇 blog。 


好 久 没 有 写 这 么 完整 的 文档 了 ， 上 次 写 还 是 三 年 前 在 学 Ng 的 ML 课程 的 时 候 ， 当 年 好 有 激情 啊 。 这 次 的 撰写 花 了 20+ 
days， 从 暑假 写 到 现在 ， 大 部 分 时 间 花 在 debug、 男 图 和 琢磨 怎么 写 上 ， 希 望 文档 能 对 大 家 和 自己 都 有 所 帮助 。 


J 
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拿 到 系统 后 ， 部 署 系统 是 第 一 件 事 ， 那 么 系统 部 署 成 功 以 后 ， 各 个 节点 都 启动 了 哪些 服务 ? 


部 四 图 
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从 部 署 图 中 可 以 看 到 


e 整个 集群 分 为 Master 节点 和 Worker 节点 ， 相 当 于 Hadoop 的 Master 和 Slave 节点 。 

e Master 节点 上 常 驻 Master 守护 进程 ， 负 责 管理 全 部 的 Worker 节点 。 

e Worker 节点 上 常 驻 Worker 守护 进程 ， 负 责 与 Master 节点 通信 并 管理 executors。 

e Driver 官方 解释 是 “The process running the main() function of the application and creating the SparkContext"。 
Application 就 是 用 户 自己 写 的 Spark 程序 (driver program) ， 比 如 WordCount.scala。 如果 driver program 在 Master 
上 运行 ， 比 如 在 Master 上 运行 


./bin/run-example SparkPi 10 


那么 SparkPi 就 是 Master 上 的 Driver。 如 果 是 YARN 集群 ， 那 么 Driver 可 能 被 调度 到 Worker 节点 上 运行 (比如 上 图 
中 的 Worker Node 2) 。 另 外 ， 如 果 直 接 在 自己 的 PC 上 运行 driver program， 比 如 在 Eclipse 中 运行 driver program， 
使 用 
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val sc = new SparkContext("spark://master:7077", "AppName") 


去 连接 master 的 话 ，driver 就 在 自己 的 PC 上 ， 但 是 不 推荐 这 样 的 方式 ， 因 为 PC 和 Workers 可 能 不 在 一 个 局 域 网 ， 
driver 和 executor 之 间 的 通信 会 很 慢 。 


e。 每 个 Worker 上 存在 一 个 或 者 多 个 ExecutorBackend 进程 。 每 个 进程 包含 一 个 Executor 对 象 ， 该 对 象 持 有 一 个 线程 
池 ， 每 个 线程 可 以 执行 一 个 task。 

e 每 个 application 包含 一 个 driver 和 多 个 executors， 每 个 executor 里 面 运行 的 tasks 都 属于 同一 个 application。 

。 在 Standalone 版 本 中 ，ExecutorBackend 被 实例 化 成 CoarseGrainedExecutorBackend 进程 。 


在 我 部 署 的 集群 中 每 个 Worker 只 运行 了 一 个 CoarseGrainedExecutorBackend 进程 ， ee 多 个 
CoarseGrainedExecutorBackend 进程 。 (应 该 是 运行 多 个 applications 的 时 候 会 产生 多 个 进程 ， 这 个 我 还 没有 实 
验 ，) 


想 了 解 Worker 和 Executor 的 关系 详情 ， 可 以 参阅 @OopsOutOfMemory 同学 写 的 Spark Executor Driver 资 源 调 
度 小 结 。 


e Worker 通过 持 有 ExecutorRunner 对 象 来 控制 CoarseGrainedExecutorBackend 的 馈 停 。 


了 解 了 部 署 图 之 后 ， 我 们 先 给 出 一 个 job 的 例子 ， 然 后 概览 一 下 job 如 何 生 成 与 运 


Job 例子 


我 们 使 用 Spark 自 带 的 examples 包 中 的 GroupByTest， 假 设 在 Master 节点 运行 ， 命 邻 是 


/* Usage: GroupByTest [numMappers] [numKVPairs] [valSize] [numReducers] */ 


bin/run-example GroupByTest 100 10000 1000 36 


GroupByTest 具体 代码 如 下 


package org.apache.spark.examples 
import java.util.Random 


import org.apache.spark. {SparkConf, SparkContext} 
import org.apache.spark.SparkContext._ 


/** 
* Usage: GroupByTest [numMappers] [numKVPairs] [valSize] [numReducers] 
0 

object GroupByTest 1{ 
def main(args: Array[String]) { 

val sparkConf = new SparkConf().setAppName("GroupBy Test") 
var numMappers = 100 

var numKVPairs = 10000 

var valSize = 1000 

var numReducers = 36 


val sc = new SparkContext(sparkConf) 


val pairs1 = sc.parallelize(0 until numMappers, numMappers).flatMap { p => 
val ranGen = new Random 
var arr1i = new Array[(Int，Array[Byte])](CnumKVPairs ) 
for (i <- 0 until numKVPairs) { 
val byteArr = new Array[Bytel](valSize) 
ranGen ,nextBytes(byteArr ) 
arr1i(i) = (ranGen.nextInt(Int.MaxValue)，byteArr ) 


arri 
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}.cache 
// Enforce that everything has been calculated and in cache 
pairsi1.count 


println(pairs1.groupByKey(numReducers).count) 


sc.stop() 


阅读 代码 后 ， 用 户头 脑 中 job 的 执行 流程 是 这 样 的 : 











pairs1 


arr1: Array[ ( random(int), Byte[1000] ) ] 
with 10000 elements 


ET 





Array[lntj(100) 
pairs1.groupByKey() 


Array[ (random(inti, Array[Byte[1000]] ) ] 


Byte[1000] | Byte[1000] | Byte[1000] 
Byte[1000] | Byte[1000] 











Byte[1000] 


| Byte[1000] 
Byte[1000] Byte[1000] 





具体 流程 很 简单 ， 这 里 来 估算 下 data size 和 执行 结果 : 


初始 化 SparkConf()。 

初始 化 numMappers=100, numKVPairs=10,000, valSize=1000, numReducers= 36。 

初始 化 SparkContext。 这 一 步 很 重要 ， 是 要 确立 driver 的 地 位 ， 里 面包 含 创建 driver 所 需 的 各 种 actors 和 objects。 

每 个 mapper 生成 一 个 arr1: Array[(Int，Byte[])] ，length 为 numKVPairs。 每 一 个 Byte[] 的 length 为 valSize，Int 

为 随机 生成 的 整数 。 Size(arri) = numKVPalirs * (4 + valSize) = 10MB ， 所 以 Size(pairs1i) = numMappers * Size(arr1) = 

1000MB 。 这 里 的 数值 计算 结果 都 是 约 等 于 。 

5. 每 个 mapper 将 产生 的 arr1 数组 cache 到 内 存 。 

6. 然后 执行 一 个 action 操作 count()， 来 统计 所 有 mapper 中 arrl 中 的 元 素 个 数 ， 执行 结果 是 numMappers * numkvPairs = 
1,000,000 。 这 一 步 主 要 是 为 了 将 每 个 mapper 产生 的 arr1 数组 cache 到 内 存 。 

7. 在 已 经 被 cache 的 paris1 上 执行 groupByKey 操作 ，groupByKey 产生 的 reducer (也 就 是 partition) 个 数 为 
numReducers。 理 论 上 ， 如 果 hash(Key) 比较 平均 的 话 ， 每 个 reducer 收 到 的 record 个 数 为 numMappers * numkvPairs / 
numReducer = 27,777 ， 大 小 为 Size(pairs1) / numReducer = 27MB 。 

8. reducer 将 收 到 的 <Int，Byte[]> records 中 拥有 相同 Int 的 records 聚 在 一 起 ， 得 到 <Int，1list(Byte[]，Byte[]，.,， 
Byte[])> 。 

9. 最 后 count 将 所 有 reducer 中 records 个 数 进行 加 和 ， 最 后 结果 实际 就 是 pairs1 中 不 同 的 Int 总 个 数 。 


DP 


Job 逻辑 执行 图 


Job 的 实际 执行 流程 比 用 户头 脑 中 的 要 复杂 ， 需 要 先 建立 逻辑 执行 图 (或 者 叫 数据 依赖 图 ) ， 然 后 划分 逻辑 执行 图 生成 DAG 
型 的 物理 执行 图 ， 然 后 生成 具体 task 执行 。 分 析 一 下 这 个 job 的 逻辑 执行 图 : 


总 体 了 绍 6 
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使 用 Rpp.topebugstring 可 以 看 到 整个 logical plan (RDD 的 数据 依赖 关系 ) 如 下 


MapPartitionsRDD[3] at groupByKey at GroupByTest.scala:51 (36 partitions) 
ShuffledRDD[2|] at groupByKey at GroupByTest.Scala:51 (36 partitions) 
FlatMappedRDD[1] at flatMap at GroupByTest ,Scala:38 (100 partitions) 
ParallelCollectionRDD[0] at parallelize at GroupByTest,Scala:38 (100 partitions) 





用 图 表示 就 是 : 
ParallelCollectionRDD FlatMappedRDD ShuffledRDD MapPartitionsRDD 
aggregate + 全 
flatMap( shuffle mapPartitions( 
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Legend: partition: (1 ) cached partition: (1 ) 
in the partition 


需要 注意 的 是 data in the partition 展示 的 是 每 个 partition 应 该 得 到 的 计算 结果 ， 并 不 意味 着 这 些 结 果 都 同时 存在 于 内 
存 中 。 
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(3, Byte[1000]) 
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(5, Byte[1000]) 


根据 上 面 的 分 析 可 知 : 


e 用 户 首先 init 了 一 个 0-99 的 数组 : 6 until numMappers 

e parallelize() 产生 最 初 的 ParrallelCollectionRDD， 每 个 partition 包含 一 个 整数 i。 

e 执行 RDD 上 的 transformation 操作 (这 里 是 flatMap) 以 后 ， 生 成 FlatMappedRDD， 其 中 每 个 partition 包含 一 个 
Array[(Int, Array[Byte])]。 

e 第 一 个 count() 执行 时 ， 先 在 每 个 partition 上 执行 count， 然 后 执行 结果 被 发 送 到 driver， 最 后 在 driver 端 进行 Sum。 

e 由 于 FlatMappedRDD 被 cache 到 内 存 ， 因 此 这 里 将 里 面 的 partition 都 换 了 一 种 颜色 表示 。 

e groupByKey 产生 了 后 面 两 个 RDD， 为 什么 产生 这 两 个 在 后 面 章节 讨论 。 

e 如 果 job 需要 shuffle， 一 般 会 产生 ShuffledRDD。 该 RDD 与 前 面 的 RDD 的 关系 类 似 于 Hadoop 中 mapper 输出 数据 
与 reducer 输入 数据 之 间 的 关系 。 

e MapPartitionsRDD 里 包含 groupByKey' 的 结果 。 

e。 最 后 将 MapPartitionsRDD 中 的 每 个 value (也 就 是 Array[Byte]) 都 转换 成 lterable 类 型 。 

e 最 后 的 count 与 上 一 个 count 的 执行 方式 类 似 。 


可 以 看 到 逻辑 执行 图 描述 的 是 job 的 数据 流 : job 会 经 过 哪些 transformation()， 中 间 生 成 哪些 RDD 及 RDD 之 间 的 依赖 关 
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Job 物理 执行 


逻辑 执行 图 表示 的 是 数据 上 的 依赖 关系 ， 不 是 task 的 执行 图 。 在 Hadoop 中 ， 用 户 直 接 面 对 task，mapper 和 reducer 的 职 
责 分 明 : 一 个 进行 分 块 处 理 ， 一 个 进行 aggregate。Hadoop 中 整个 数据 流 是 固定 的 ， 只 需要 填充 map() 和 reduce() 函数 即 
可 。Spark 面 对 的 是 更 复杂 的 数据 处 理 流程 ， 数 据 依赖 更 加 灵活 ， 很 难 料 数据 流 和 物理 task 简单 地 统一 在 一 起 。 因 此 Spark 
将 数据 流 和 具体 task 的 执行 流程 分 开 ， 并 设计 算法 将 逻辑 执行 图 转换 成 task 物理 执行 图 ， 转 换算 法 后 面 的 章节 讨论 。 


针对 这 个 job， 我 们 先 画 出 它 的 物理 执行 DAG 图 如 下 : 
ParallelCollectionRDD FlatMappedRDD ShuffledRDD MapPartitionsRDD MappedwaluesRDD 
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Legend: | RDD partition: cached partition: : assumed data 
in the partition/result | 


可 以 看 到 GroupByTest 这 个 application 产生 了 两 个 job， 第 一 个 job 由 第 一 个 action (也 就 是 pairsi.count ) 触发 产生 ， 分 


析 二 下 第 二 个 0b: 
e 整个 job 只 包含 1 个 stage (不 明白 什么 是 stage 没 天 系 ， 后 面 章节 会 解释 ， 这 里 只 需 知道 有 这 样 一 个 概念 ) 。 


Stage 0 包含 100 个 ResultTask。 

每 个 task 先 计算 flatMap， 产 生 FlatMappedRDD， 然 后 执行 action() 也 就 是 count()， 统 计 每 个 partition 里 records 的 
个 数 ， 上 比如 partition 99 里 面 只 含有 9 个 records。 

由 于 pairs1 被 声明 要 进行 cache， 因 此 在 task 计算 得 到 FlatMappedRDD 后 会 将 其 包含 的 partitions 都 cache 到 
executor 的 内 存 。 

task 执行 完 后 ，driver 收集 每 个 task 的 执行 结果 ， 然 后 进行 sum()。 

job 0 结束 。 


第 二 个 job 由 pairsi.groupByKey(numReducers).count 触发 产生 。 分 析 一 下 该 job : 
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整个 job 包含 2 个 stage。 

Stage 1 包含 100 个 ShuffleMapTask， 每 个 task 负责 从 cache 中 读 取 pairs1 的 一 部 分 数据 并 将 其 进行 类 似 Hadoop 中 
mapper 所 做 的 partition， 最 后 将 partition 结果 写 人 本 地 磁盘 。 

Stage 0 包含 36 个 ResultTask， 六 task 首先 shuffle 自己 要 处 理 的 数据 ， 边 fetch 数据 边 进 行 aggregate 以 及 后 续 的 
mapPartitions() 操作 ， 最 后 进行 count() 计算 得 到 result。 

task 执行 完 后 ，driver 收集 每 个 task 的 执行 结果 ， 然 后 进行 Sum()。 

job 1 结 


可 以 看 到 物理 执行 图 并 不 简单 。 与 MapReduce 不 同 的 是 ，Spark 中 一 个 application 可 能 包含 多 个 job， 每 个 job 包含 多 个 
stage， 每 个 stage 包含 多 个 task。 人 怎么 划分 job， 怎 么 划分 stage， 人 怎么 划分 task 等 等 问题 会 在 后 面 的 章节 介绍 。 


Discussion 


到 这 里 ， 我 们 对 整个 系统 和 job 的 生成 与 执行 有 了 概念 ， 而 且 还 探讨 了 cache 等 特性 。 接 下 来 的 章节 会 讨论 job 生成 与 执行 
涉及 到 的 系统 核心 功能 ， 包 括 : 


~| OO 人 售 Dc- 


.如 何 生成 逻辑 执行 图 

.如 何 生成 物理 执行 图 

.如 何 提 交 与 调度 Job 

.Task 如 何 生成 、 执 行 与 结果 义理 
如何 进行 shuffle 

. cache 机 制 

.broadcast 机 制 
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Job 远 辑 执行 图 
General logical plan 


Data blocks 1 RDD | RDD m final RDD Results 


createRDDI( 






shuffle transformation() € action() 


result of 


f() 


典型 的 Job 逮 辑 执行 图 如 上 所 示 ， 经 过 下 面 四 个 步骤 可 以 得 到 最 终 执行 结果 : 


e 从 数据 源 (可 以 是 本 地 fle， 内 存 数据 结构 ， HDFS，HBase 等 ) 读 取 数据 创建 最 初 的 RDD。 上 一 章 例 子 中 的 
parallelize() 相当 于 createRDD()。 

e 对 RDD 进行 一 系列 的 transformation() 操作 ， 每 一 个 transformation() 会 产生 一 个 或 多 个 包含 不 同类 型 TT 的 RDD[T]。T 
可 以 是 Scala 里 面 的 基本 类 型 或 数据 结构 ， 不 限于 (K, V)。 但 如 果 是 (K, V)，K 不 能 是 Array 等 复杂 类 型 (因为 难以 在 
复杂 类 型 上 定义 partition 函数 ) 。 

e 对 最 后 的 final RDD 进行 action() 操作 ， 每 个 partition 计算 后 产生 结果 result。 

e。 将 result 回 送 到 driver 端 ， 进 行 最 后 的 fllist[resul) 计算 。 例 子 中 的 count() 实际 包含 了 action() 和 Sum() 两 步 计 算 。 


RDD 可 以 被 cache 到 内 存 或 者 checkpoint 到 磁盘 上 。RDD 中 的 partition 个 数 不 固 定 ， 通 常 由 用 户 设 定 。RDD 和 
RDD 之 间 partition 的 依赖 关系 可 以 不 是 1 对 1， 如 上 图 既 有 1 对 1 关系 ， 也 有 多 对 多 的 关系 。 


逻辑 执行 图 的 生成 


了 解 了 Job 的 逻辑 执行 图 后 ， 写 程序 时 候 会 在 脑 中 形成 类 似 上 面 的 数据 依赖 图 。 然 而 ， 实 际 生 成 的 RDD 个 数 往往 比 我 们 想 
想 的 个 数 多 。 


要 解决 远 辑 执行 图 生成 问题 ， 实 际 需 要 解决 : 


e 如 何 产 生 RDD， 应 该 产生 哪些 RDD? 
e 如 何 建 立 RDD 之 间 的 依赖 关系 ? 


1. 如 何 产生 RDD， 应 该 产生 哪些 RDD ? 


解决 这 个 问题 的 初步 想法 是 让 每 一 个 transformation() 方法 返回 (new) 一 个 RDD。 事 实 也 基本 如 此 ， 只 是 某 些 
transformation() 比较 复杂 ， 会 包含 多 个 子 transformation()， 因 而 会 生成 多 个 RDD。 这 融 是 实际 RDD 个 数 比 我 们 想象 的 多 
一 些 的 原因 。 


如 何 计算 每 个 RDD 中 的 数据 ?逻辑 执行 图 实际 上 是 computing chain， 那 么 transformation() 的 计算 逻辑 在 哪里 被 
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perform ? 每 个 RDD 里 有 compute() 方法 ， 负 责 接 收 来 自 上 一 个 RDD 或 者 数据 源 的 input records，perform 
transformation() 的 计算 逻辑 ， 然 后 输出 records。 


产生 哪些 RDD 与 transformation() 的 计算 逻辑 有 关 ， 下 面 讨论 一 些 典 型 的 transformation() 及 其 创建 的 RDD。 官 网 上 已 经 解 
释 了 每 个 transformation 的 含义 。iterator(splib 的 意思 是 foreach record in the partition。 这 里 空 了 很 多 ， 是 因为 那些 
transformation() 较为 复杂 ， 会 产生 多 个 RDD， 具 体会 在 下 一 节 图 示 出 来 。 


Transformation Generated RDDs Compute() 

map(func) MappedRDD iterator(split).map(f) 
filter(func) FilteredRDD iterator(split).filter(f) 
flatMap(func) FlatMappedRDD iterator(split).flatMap(f) 
mapPartitions(func) MapPartitionsRDD f(iterator(split)) 
mapPartitionsWithlndex(func) MapPartitionsRDD f(split.Index, iterator(split)) 


sample(withReplacement, 
fraction, seed) 


PolissonSampler.samplel(iterator(split)) 
BernoulliSampler.sample(iterator(split)) 


PartitionwiseSampledRDD 
pipe(command, [envVars]) PipedRDD 
union(otherDataset) 

intersection(otherDataset) 

distinct([numTasks])) 

groupByKey([numTasks]) 


reduceByKey(func， 
[numTasks]) 


sortByKey([ascending], 
[numTasks]) 


join(otherDataset, [num Tasks]) 


cogroup(otherDataset, 
[numTasks]) 


cartesian(otherDataset) 
coalesce(numPartitions) 


repartition(numPartitions) 


2. 如 何 建立 RDD 之 间 的 联系 ? 
RDD 之 间 的 数据 依赖 问题 实际 包括 三 部 分 : 


e RDD 本 身 的 依赖 关系 。 要 生成 的 RDD (以 后 用 RDD x 表示 ) 是 依赖 一 个 parent RDD， 还 是 多 个 parent RDDs? 
e RDD x 中 会 有 多 少 个 partition ? 
e RDD x 与 其 parent RDDs 中 partition 之 间 是 什么 依赖 关系 ?是 依赖 parent RDD 中 一 个 还 是 多 个 partition ? 


第 一 个 问题 可 以 很 自然 的 解决 ， 比 如 x = rdda.transformation(rddb) (e.g., Xx = a.join(b)) 就 表示 RDD x 同时 依赖 于 RDD a 和 
RDD b。 


第 二 个 问题 中 的 partition 个 数 一 般 由 用 户 指定 ， 不 指定 的 话 一 般 取 max(numPartitions[parent RDD 1], .., 


numPartitions[parent RDD Nn])。 


第 三 个 问题 比较 复杂 。 需 要 考虑 这 个 transformation() 的 语义 ， 不 同 的 transformation0 的 依赖 关系 不 同 。 比 如 map0 是 
1:1， 而 groupByKey() 逻辑 执行 图 中 的 ShuffledRDD 中 的 每 个 partition 依赖 于 parent RDD 中 所 有 的 partition， 还 有 更 复杂 
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的 情 况 。 


再 次 考虑 第 三 个 问题 ，RDD x 中 每 个 partition 可 以 依赖 于 parent RDD 中 一 个 或 者 多 个 partition。 而且 这 个 依赖 可 以 是 完 
依赖 或 者 部 分 依赖 。 部 分 依赖 指 的 是 parent RDD 中 某 partition 中 一 部 分 数据 与 RDD x 中 的 一 个 partition 相关 ， 另 一 部 分 数 
据 与 RDD x 中 的 另 一 个 partition 相关 。 下 图 展示 了 完全 依赖 和 部 分 依赖 。 


FullDependency 1:1 FullDependency N:1 
PRDD a RDD x PRDD a RDD x 





PartialDependency 
RDD a RDD x RDD a RDD x 





前 三 个 是 完全 依赖 ，RDD x 中 的 partition 与 parent RDD 中 的 partition/partitions 完全 相关 。 最 后 一 个 是 部 分 依赖 ，RDD x 
中 的 partition 只 与 parent RDD 中 的 partition 一 部 分 数据 相关 ， 另 一 部 分 数据 与 RDD x 中 的 其 他 partition 相关 。 


在 Spark 中 ， 完 全 依赖 被 称 为 NarrowDependency， 部 分 依赖 被 称 为 ShuffleDependency。 其 实 ShuffleDependency 跟 
MapReduce 中 shuffle 的 数据 依赖 相同 (mapper 将 其 output 进行 partition， 然 后 每 个 reducer 会 将 所 有 mapper 输出 中 属 
于 自己 的 partition 通过 HTTP fetch 得 到 ) 。 


第 一 种 1:1 的 情况 被 称 为 OneToOneDependency。 

。 第 二 种 N:1 的 情况 被 称 为 N:1 NarrowDependency。 

e 第 三 种 N:N 的 情况 被 称 为 N:N NarrowDependency。 不 属于 前 两 种 情况 的 完全 依赖 都 属于 这 个 类 别 。 
e 第 四 种 被 称 为 ShuffleDependency。 


对 于 NarrowDependency， 具 体 RDD x 中 的 partitoin i 依赖 parrent RDD 中 一 个 partition 还 是 多 个 partitions， 是 由 RDD x 
中 的 getpParents(partition i) 决定 (下 图 中 某 些 例子 会 详细 介绍 ) 。 还 有 一 种 RangeDependency 的 完全 依赖 ， 不 过 该 依 
赖 目前 只 在 UnionRDD 中 使 用 ， 下 面 会 介绍 。 


所 以 ， 总 结 下 来 partition 之 间 的 依赖 关系 如 下 : 


e NarrowDependency (使 用 黑色 实 线 或 黑色 虚线 箭头 表示 ) 
o OneTooOneDependency (1:1) 
m NarrowDependency (N:1) 
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o NarrowDependency (N:N) 
o RangeDependency (只 在 UnionRDD 中 使 用 ) 
e。 ShuffleDependency (使 用 红色 箭头 表示 ) 


之 所 以 要 划分 NarrowDependency 和 ShuffleDependency 是 为 了 生成 物理 执行 图 ， 下 一 章 会 具体 介绍 。 


需要 注意 的 是 第 三 种 NarrowDependency (N:N) 很 少 在 两 个 RDD 之 间 出 现 。 因 为 如 果 parent RDD 中 的 partition 同时 
被 child RDD 中 多 个 partitions 依赖 ， 那 么 最 后 生成 的 依赖 图 往往 与 ShuffleDependency 一 样 。 只 是 对 于 parent RDD 
中 的 partition 来 说 一 个 是 完全 依赖 ， 一 个 是 部 分 依赖 ， 而 箭头 数 没 有 少 。 所 以 Spark 定义 的 NarrowDependency 其 实 
是 “each partition of the parent RDD is used by at most one partition of the child RDD“， 也 就 是 只 有 
OneToOneDependency (1:1) 和 NarrowDependency (N:1) 两 种 情况 。 但 是 ， 自 己 设计 的 奇 划 RDD 确实 可 以 呈现 出 
NarrowDependency (N:N) 的 情况 。 这 里 摘 述 的 比较 乱 ， 其 实 看 懂 下 面 的 几 个 典型 的 RDD 依赖 即 可 。 


如 何 计 算得 到 RDD x 中 的 数据 (records) ?下 图 展示 了 OneToOneDependency 的 数据 依赖 ， 虽 然 partition 和 partition 之 
间 是 1:1， 但 不 代表 计算 records 的 时 候 也 是 读 一 个 record 计算 一 个 record。 下 图 右边 上 下 两 个 pattern 之 间 的 差别 类 似 于 
下 面 两 个 程序 的 差别 : 


OneToOneDependency iter.f0 
(e.g., map!(f), filter(f), flatMap!(f)) 


RDD 1 RDD x 





f(iter) 
(e.9., MapPartitions(f), mapPartitionsWithindex(f), 
pipe(comMmandgd)) 


Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ed 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ld 
Ed 
Ld 
Ld 
Ld 
一 一 一 一 一 一 一 一 
~~---------- 
~ 一 一 一 一 一 一 





code1 of iter.f() 


na E25 
fionante = 0 earmrav Len 
f(array[i]) 


code2 of f(iter) 


sale] Ee ei 2 7 
f(array) 


3. 给 出 一 些 典 型 的 transformation() 的 计算 过 程 及 数据 依赖 图 


1) union(otherRDD) 
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uniont: RangeDependency 


RDD 1 UnionRDD 





union0 将 两 个 RDD 简单 合并 在 一 起 ， 不 改变 partition 里 面 的 数据 。RangeDependency 实际 上 也 是 1:1， 只 是 为 了 访问 
union() 后 的 RDD 中 的 partition 方便 ， 保 留 了 原始 RDD 的 range 边界 。 


2) groupByKey(numPartitions) 
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qroupByKey(numPartitions) 


ohuffledRDD MapPartitionsRDD 





Example: groupByKeyi2) 


ParalleluollectionRDD ohuffledRDD MapPartitionsRDD 


4, ArrayButfer(d} 
2, ArrayBuffertb, g) 


1, ArrayButfer(a, h} 
3, ArrayButfferlc, f) 
5, ArrayButferle) 





上 一 章 已 经 介绍 了 groupByKey 的 数据 依赖 ， 这 里 算是 温 故 而 知 新 吧 。 


groupByKey() 只 需要 将 Key 相同 的 records 聚合 在 一 起 ， 一 个 简单 的 shuffle 过 程 就 可 以 完成 。ShuffledRDD 中 的 
compute() 只 负责 将 属于 每 个 partition 的 数据 fetch 过 来 ， 之 后 使 用 mapPartitions() 操作 (前 面 的 oneuoons Dopen ney 
展示 过 ) 进行 aggregate， 生 成 MapPartitionsRDD， 到 这 里 groupByKey( 已 经 结束 。 最 后 为 了 统一 返回 值 接口 ， 将 value 
中 的 ArrayBuffer 数据 结构 抽象 化 成 lterable[]。 


groupByKey() 没有 在 map 端 进行 combine， 因 为 map 端 combine 只 会 省 掉 partition 里 面 重复 key 占用 的 空间 ， 当 
重复 key 特别 多 时 ， 可 以 考虑 开启 combine。 


这 里 的 ArrayBuffer 实际 上 应 该 是 CompactBuffer，An append-only buffer similar to ArrayBuffer but more memory- 
efficient for small buffers. 


ParallelCollectionRDD 是 最 基础 的 RDD， 直 接 从 local 数据 结构 create 出 的 RDD 属于 这 个 类 型 ， 比 如 
vadlmeanmse Seanellel ze( sn 2 9004905 3 


生成 的 pairs 就 是 ParallelCollectionRDD。 


2) reduceyByKey(func, numPartitions) 
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reduceByKeyit, numPartitions) 


RDDa MapPartitionsRDD ohuffledRDD MapPartitionsRDD 





Example (WordCGount): reduceByKey!_ + _, 2) 
parallelGollectionRDGD MapPpartitionsRDD ShuffledRDD MapPartitionsRDD 





reduceyByKey() 相当 于 传统 的 MapReduce， 整 个 数据 流 也 与 Hadoop 中 的 数据 流 基本 一 样 。reduceyByKey() 默认 在 map 
端 开 和 启 combine()， 因 此 在 shuffle 之 前 先 通过 mapPartitions 操作 进行 combine， 得 到 MapPartitionsRDD， 然 后 shuffle 得 
到 ShuffledRDD， 然 后 再 进行 reduce (通过 aggregate + mapPartitions() 操作 来 实现 ) 得 到 MapPartitionsRDD。 


3) distinct(numPartitions) 
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distincttnumPartitions) 


RDD a MappedRDD MapPartitionsRDD ShuffledRDD MapPartitionsRDD MappedRDD 





Example: distinct(2) 
- represents null 


ParallelCollection MappedRDD 


RDD MapPartitionsRDD ShuffledRDD MapPartitionsRDD MappedRDD 





distinct() 功能 是 deduplicate RDD 中 的 所 有 的 重复 数据 。 由 于 重复 数据 可 能 分 散在 不 同 的 partition 里 面 ， 因 此 需要 shuffle 
来 进行 aggregate 后 再 去 重 。 然 而 ，shuffle 要 求 数据 类 型 是 <k，v> 。 如 果 原 始 数据 只 有 Key (比如 例子 中 record 只 有 一 个 
整数 ) ， 那 么 需要 补充 成 <k，null> 。 这 个 补充 过 程 由 map( 操作 完成 ， 生 成 MappedRDD。 然 后 调用 上 面 的 
reduceByKey() 来 进行 shuffle， 在 map 端 进行 combine， 然 后 reduce 进一步 去 重 ， 生 成 MapPartitionsSRDD。 最 后 ， 将 
<K，null> 还 原 成 K， 仍 然 由 map() 完成 ， 生 成 MappedRDD。 蓝 色 的 部 分 就 是 调用 的 reduceByKey()。 


4) cogroup(otherRDD, numPartitions) 
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RDDa a.cogroup(b, numPartitions = 4) RDD a a.cogroup(b, partitioner) 
if a.Partitioner = partitioner 
(I.e., CoGroupedRDD.Partitioner) 


CoGroupedRDD MappedValuesRDD 
~ ; 











CoGroupedRDD MappedValuesRDD 














RDD a a.cogroup(b, partitioner) 
if a.Partitioner = b.Partitioner = 
CoGroupedRDD.Partitioner 


Example of a.cogroup(b) 
a.Partitioner = CoGroupedRDD.Partitioner 
= RangePartitioner(3) 


RDD a 


CoGroupedRDD MappedValuesRDD CoGroupedRDD MappedValuesRDD 


与 groupByKey( 不 同 ，cogroup() 要 aggregate 两 个 或 两 个 以 上 的 RDD。 那 么 CoGroupedRDD 与 RDD a 和 RDD b 的 关 
系 都 必须 是 ShuffleDependency 么 ? 是否 存在 OneToOneDependency ? 


首先 要 明确 的 是 CoGroupedRDD 存在 几 个 partition 可 以 由 用 户 直 接 设 定 ， 与 RDD a 和 RDD b 无 关 。 然 而 ， 如 果 
CoGroupedRDD 中 partition 个 数 与 RDD a/b 中 的 partition 个 数 不 一 样 ， 那 么 不 可 能 存在 1:1 的 关系 。 


再 次 ，cogroupf) 的 计算 结果 放 在 CoGroupedRDD 中 哪个 partition 是 由 用 户 设 置 的 partitioner 确定 的 〈 默 认 是 
HashPartitioner) 。 那 么 可 以 推出 : 即使 RDD ayb 中 的 partition 个 数 与 CoGroupedRDD 中 的 一 样 ， 如 果 RDD ay/b 中 的 
partitioner 与 CoGroupedRDD 中 的 不 一 样 ， 也 不 可 能 存在 1:1 的 关系 。 比 如 ， 在 上 图 的 example 里 面 ，RDD a 是 
RangePartitioner，b 是 HashPartitioner，CoGroupedRDD 也 是 RangePartitioner 且 partition 个 数 与 a 的 相同 。 那 么 很 自然 
地 ，a 中 的 每 个 partition 中 records 可 以 直接 送 到 CoGroupedRDD 中 对 应 的 partition。RDD b 中 的 records 必须 再 次 进行 
划分 与 shuffle 后 才能 进入 对 应 的 partition。 


最 后 ， 经 过 上 面 分 析 ， 对 于 两 个 或 两 个 以 上 的 RDD 聚合 ， 当 且 人 入 当 聚合 后 的 RDD 中 partitioner 类 别 及 partition 个 数 与 前 
面 的 RDD 都 相同 ， 才 会 与 前 面 的 RDD 构成 1:1 的 关系 。 否 则 ， 只 能 是 ShuffleDependency。 这 个 算法 对 应 的 代码 可 以 
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在 CoGroupedRDD .getDependencies() 中 找到 ， 虽然 比较 难 理解 。 
Spark 代码 中 如 何 表 示 CoGroupedRDD 中 的 partition 依赖 于 多 个 parent RDDs 中 的 partitions ? 


首先 ， 将 CoGroupedRDD 依赖 的 所 有 RDD 放 进 数组 rdds[RDD] 中 。 再 次 ，foreach i， 如 果 CoGroupedRDD 和 
rdds(i) 对 应 的 RDD 是 OneToOneDependency 关系， 那么 Dependecyli] = new OneTooOneDependency(rdd)， 否 则 = 
new ShuffleDependency(rdd)。 最 后 ， 返 回 与 每 个 parent RDD 的 依赖 关系 数组 deps[Dependency]。 


Dependency 类 中 的 getParents(partition id) 负责 给 出 某 个 partition 按照 该 dependency 所 依赖 的 parent RDD 中 的 
partitions: List[Int]j。 


getPartitions() 负责 给 出 RDD 中 有 多 少 个 partition， 以 及 每 个 partition 如 何 序 列 化 。 


5) Intersection(otherRDD) 


a.intersection(b) 
MappedRDD 







MappedRDD 


Example of a.intersection(b) 
- represents ‘null 


N CoGroupedRDD MappedValuesRDD 
Ee 

SS 1 LE 
Bi 


\ 
SA I 
Bin 


RDD a MappedRDD 


FilteredRDD MappedRDD 






















RDD b 站 


intersection() 功能 是 抽取 出 RDD a 和 RDD b 中 的 公共 数据 。 先 使 用 map() 将 RDDIT] 转变 成 RDD[(T nul)]， 这 里 的 下 只 
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要 不 是 Array 等 集合 类 型 即 可 。 接 着 ， 进 行 a.cogroup(b)， 蓝 色 部 分 与 前 面 的 cogroup( 一 样 。 之 后 再 使 用 filter() 过 滤 掉 
[iter(groupA()), iter(groupBO) 中 groupA 或 groupB 为 空 的 records， 得 到 FilteredRDD。 最 后 ， 使 用 keys( 只 保留 key 即 
可 ， 得 到 MappedRDD。 


6) join(otherRDD, numPartitions) 
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a.join(b) 


RDD a 





CoGroupedRDD MappedValuesRDD FlatMappedValuesRDD 





ParallelCollectionRDD 1 Example of a.join(b) 
RDD1.partitioner != CoGroupedRDD.partitioner 





FlatMappedValuesRDD 


CoGroupedRDD MappedValuesRDD 





















4, [it(d), it(D)] 
1, [it(a, h), it(A)] 


4, [(d), (D)] 
1, [(a, h), (A)] 


ParallelCollectionRDD 
5, [(e), 0] 
2 2, [(b, 9), (B)] 











5, [it(e), it()] 
2, [it(b, g), it(B)] 


ParallelCollectionRDD 1 Example of a.join(b) 
RDD1.partitioner = CoGroupedRDD.partitioner 
= HashPartitioner(3) 


CoGroupedRDD MappedValuesRDD FlatMappedValuesRDD 


4, [(d), (D)] 4, [it(d), it(D)] 
1, [(a, h), (A)] 1, [it(a, h), it(A)] 


5, [(e), 0] 5, [it(e), itO)] 
2, [it(b, g), it(B)] 
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join0 将 两 个 RDD[(K, V)] 按照 SQL 中 的 join 方式 聚合 在 一 起 。 与 intersection() 类 似 ， 首 先进 行 cogroup()， 得 到 <k， 
(Iterable[V1]，Iterable[V2])> 类 型 的 MappedValuesRDD， 然 后 对 lterable[V1] 和 lterable[V2] 做 笛 卡 尔 集 ， 并 将 集合 flat0 
化 。 


这 里 给 出 了 两 个 example， 第 一 个 example 的 RDD 1 和 RDD 2 使 用 RangePartitioner 划分 ， 而 CoGroupedRDD 使 用 
HashPartitioner， 与 RDD 1/2 都 不 一 样 ， 因 此 是 ShuffleDependency。 第 二 个 example 中 ， RDD 1 事先 使 用 
HashPartitioner 对 其 key 进行 划分 ， 得 到 三 个 partition， 与 CoGroupedRDD 使 用 的 HashPartitioner(3) 一 致 ， 因 此 数据 依 
赖 是 1:1。 如 果 RDD 2 事先 也 使 用 HashPartitioner 对 其 key 进行 划分 ， 得 到 三 个 partition， 那 么 join0 就 不 存在 
ShuffleDependency 了 ， 这 个 join(0 也 就 变 成 了 hashjoin()。 


7) sortByKey(ascending, numPartitions) 


sortByKeylascending, numPartitions) 


ohuffledRDD MapPartitionsRDD 





Example of sortByKeyitrue, 2) 


ParallelGollectionRDD ohufttledRDD MapPartitionsRDD 





sortByKey( 将 RDD[(K, V)] 中 的 records 按 key 排序 ，ascending = true 表示 升序 ，false 表示 降序 。 目 前 sortByKey() 的 数 
据 依 赖 很 简单 ， 先 使 用 shuffle 将 records 聚集 在 一 起 ( 放 到 对 应 的 partition 里 面 ) ， 然 后 将 partition 内 的 所 有 records 按 
key 排序 ， 最 后 得 到 的 MapPartitionsRDD 中 的 records 就 有 序 了 。 


目前 sortByKey() 先 使 用 Array 来 保存 partition 中 所 有 的 records， 再 排序 。 


8) cartesian(otherRDD) 
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a.cartesian(b) Example of a.cartesian(b) 


RDD a CartesianRDD RDD a CartesianRDD 


(1, a), (1, A) 
(2, b), (1, A) 


(1, a), (2, B) 
(2, b), (2, B) 


(3, c), (1, A) 
(4, d), (1, A) 





Cartesian 对 两 个 RDD 做 笛 卡 尔 集 ， 生 成 的 CartesianRDD 中 partition 个 数 = partitionNum(RDD a) * partitionNum(RDD 
b)。 


这 里 的 依赖 关系 与 前 面 的 不 太一 样 ，CartesianRDD 中 每 个 partition 依赖 两 个 parent RDD， 而 且 其 中 每 个 partition 完全 依赖 
RDD a 中 一 个 partition， 同 时 又 完全 依赖 RDD b 中 另 一 个 partition。 这 里 没有 红色 箭头 ， 因 为 所 有 依赖 都 是 


NarrowDependency。 


CartesianRDD.getDependencies() 返回 rdds[RDD a, RDD bl]。CartesianRDD 中 的 partiton i 依赖 于 (RDD a).List(i/ 
numpPartitionsInRDDb) 和 (RDD b).List(i % numPartitionsInRDDb)。 


9) coalesce(numPartitions, shuffle = false) 
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a.coalesce(numPartitions, shuffle = falsey) Example: a.coalesce(3, shuffle = false) 


RDD a RDD a 
CoalescedRDD 





CoalescedRDD 





a.coalesce(numPartitions, shuffle = true) 
RDD a MapPartitionsRDD 


ShuffledRDD CoalescedRDD MappedRDD 


Example: a.coalesce(3, shuffle = true,) 


RDD a MapPartitionsRDD 


ShuffledRDD CoalescedRDD MappedRDD 





coalesce() 可 以 将 parent RDD 的 partition 个 数 进行 调整 ， 比 如 从 5 个 减少 到 3 个 ， 或 者 从 5 个 增加 到 10 个 。 需 要 注意 的 
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是 当 shuffle = false 的 时 候 ， 是 不 能 增加 partition 个 数 的 (不 能 从 5 个 变 为 10 个 ) 。 
coalesce( 的 核心 问题 是 如 何 确立 CoalescedRDD 中 partition 和 其 parent RDD 中 partition 的 关系 。 


e@ coalesce(shuffle = false) 时 ， 由 于 不 能 进行 shuffle， 问 题 变 为 parent RDD 中 哪些 partition 可 以 合并 在 一 起 。 合 并 因 
素 除 了 要 考虑 partition 中 元 素 个 数 外 ， 还 要 考虑 locality 及 balance 的 问题 。 因 此 ，Spark 设计 了 一 个 非常 复杂 的 算法 
来 解决 该 问题 (算法 部 分 我 还 没有 深究 ) o 注意 Example: a.coalesce(3, shuffle = false) 展示 了 N:1 的 
NarrowDependency。 

e coalesce(shuffle = true) 时 ， 由 于 可 以 进行 shuffle， 问 题 变 为 如 何 将 RDD 中 所 有 records 平均 划分 到 N 个 partition 
中 。 很 简单 ， 在 每 个 partition 中 ， 给 每 个 record 附加 一 个 key，key 递增 ， 这 样 经 过 hash(key) 后 ，key 可 以 被 平均 分 
配 到 不 同 的 partition 中 ， 类 似 Round-robin 算法 。 在 第 二 个 例子 中 ，RDD a 中 的 每 个 元 素 ， 先 被 加 上 了 递增 的 key (如 
MapPartitionsRDD 第 二 个 partition 中 (1, 3) 中 的 1) 。 在 每 个 partition 中 ， 第 一 个 元 素 (Key, Value) 中 的 key 由 (new 
Random(index)).nextInt(numpartitions) 计算 得 到 ，index 是 该 partition 的 索引 ，numPartitions 是 CoalescedRDD 中 的 
partition 个 数 。 接 下 来 元 素 的 key 是 递增 的 ， 然 后 shuffle 后 的 ShuffledRDD 可 以 得 到 均 分 的 records， 然 后 经 过 复 条 算 
法 来 建立 ShuffledRDD 和 CoalescedRDD 之 间 的 数据 联系 ， 最 后 过 滤 掉 key， 得 到 coalesce 后 的 结果 MappedRDD。 


10) repartition(numPartitions) 


等 价 于 coalesce(numPartitions, shuffle = true) 


Primitive transformation() 


combineByKey() 
分 析 了 这 么 多 RDD 的 逻辑 执行 图 ， 它 们 之 间 有 没有 共同 之 处 ? 如 果 有 ， 是 怎么 被 设计 和 实现 的 ? 


仔细 分 析 RDD 的 逻辑 执行 图 会 发 现 ，ShuffleDependency 左边 的 RDD 中 的 record 要 求 是 <key, value> 型 的 ， 经 过 
ShuffleDependency 后 ， 包 含 相 同 key 的 records 会 被 aggregate 到 一 起 ， 然 后 在 aggregated 的 records 上 执行 不 同 的 计算 
远 辑 。 实 际 执行 时 (后面 的 章节 会 具体 谈 到 ) 很 多 transformation() 如 groupByKey(，reduceByKey() 是 边 aggregate 数据 
边 执 行 计算 逻辑 的 ， 因 此 共同 之 处 就 是 aggregate 同时 compute()。Spark 使 用 combineByKey() 来 实现 这 个 aggregate + 
compute0 的 基础 操作 。 


combineByKey(0) 的 定义 如 下 : 


def combineByKey[Cj(createCombiner: V => C, 
mergeValue: (C，V) => C, 
mergeCombiners: (C, C) => C, 
partitioner: Partitioner, 
mapSideCombine: Boolean = true, 
serializer: Serializer = null): RDD[(K, C)] 


假设 一 组 具有 相同 K 的 <K, V> records 正在 一 个 个 流向 combineByKey()，createCombiner 将 第 一 个 record 的 value 初始 
化 为 c (上 比如 ，c = value) ， 然 后 从 第 二 个 record 开始 ， 来 一 个 record 就 使 用 mergeValue(c, record.value) 来 更 新 c， 比 
如 想 要 对 这 些 records 的 所 有 values 做 sum， 那 么 使 用 c = c + record.value。 等 到 records 全 部 被 mergeValue()， 人 得 到 结 
果 c。 假 设 还 有 一 组 records (key 与 前 面 那 组 的 key 均 相 同 ) 一 个 个 到 来 ，combineByKey() 使 用 前 面 的 方法 不 断 计 算得 到 
c'。 现 在 如 果 要 求 这 两 组 records 总 的 combineByKey() 后 的 结果 ， 那 么 可 以 使 用 final c = mergeCombiners(c, c') 来 计算 。 


Discussion 
至 此 ， 我 们 讨论 了 如 何 生 成 job 的 逻辑 执行 图 ， 这 些 图 也 是 Spark 看 似 简 单 的 API 背后 的 复杂 计算 逻辑 及 数据 依赖 关系 。 
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整个 job 会 产生 哪些 RDD 由 transformation( 语义 决定 。 一 些 transformation()， 比如 cogroup0 会 被 很 多 其 他 操作 用 到 。 


RDD 本 身 的 依赖 关系 由 transformation() 生成 的 每 一 个 RDD 本 身 语义 决定 。 如 CoGroupedRDD 依赖 于 所 有 参加 cogroup() 
的 RDDs。 


RDD 中 partition 依赖 关系 分 为 NarrowDependency 和 ShuffleDependency。 前 者 是 完全 依赖 ， 后 者 是 部 分 依赖 。 
NarrowDependency 里 面 又 包含 多 种 情况 ， 只 有 前 后 两 个 RDD 的 partition 个 数 以 及 partitioner 都 一 样 ， 才 会 出 现 
NarrowDependency。 


从 数据 处 理 迅 辑 的 角度 来 看 ，MapReduce 相当 于 Spark 中 的 map( + reduceByKey()， 但 严格 来 讲 MapReduce 中 的 
reduce() 要 比 reduceByKey() 的 功能 强大 些 ， 详 细 差 别 会 在 Shuffle details 一 章 中 继续 讨论 。 
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Job 物理 执行 图 


在 Overview 里 我 们 初步 介绍 了 DAG 型 的 物理 执行 图 ， 里 面包 含 stages 和 tasks。 这 一 章 主 要 解决 的 问题 是 : 


给 定 job 的 逻辑 执行 图 ， 如 何 生 成 物理 执行 图 (也 就 是 stages 和 tasks) ? 
人 -一 四 、 一 J 
一 个 复杂 job 的 逻辑 执行 图 


ComplexJob 
including map(, partitionBy(), union(), and join() 


ShuffledRDD 


©@ Ne MappedValuesRDD FlatMappedValuesRDD 


oe) 
UnioinRDD CN 计时 ee 
BO 个 
= 0 Ms 

















MappedRDD 





代码 贴 在 本 章 最 后 。 给 定 这 样 一 个 复杂 数据 依赖 图 ， 如 何 合 理 划 分 stage， 并 确定 task 的 类 型 和 个 数 ? 


一 个 直观 想法 是 将 前 后 关联 的 RDDs 组 成 一 个 stage， 每 个 箭头 生成 一 个 task。 对 于 两 个 RDD 聚合 成 一 个 RDD 的 情况 ， 这 
三 个 RDD 组 成 一 个 stage。 这 样 虽然 可 以 解决 问题 ， 但 显然 效率 不 高 。 除 了 效率 问题 ， 这 个 想法 还 有 一 个 更 严重 的 问题 : 大 
量 中 间 数 据 需要 存储 。 对 于 task 来 说 ， 其 执行 结果 要 么 要 存 到 磁盘 ， 要 么 存 到 内 存 ， 或 者 两 者 此 有 。 如 果 每 个 箭头 都 是 task 
的 话 ， 每 个 RDD 里 面 的 数据 都 需要 存 起 来 ， 占 用 空间 可 想 而 知 。 


仔细 观察 一 下 逻辑 执行 图 会 发 现 : 在 每 个 RDD 中 ， 每 个 partition 是 独立 的 ， 也 就 是 说 在 RDD 内 部 ， 每 个 partition 的 数据 


依赖 各 自 不 会 相互 干扰 。 因 此 ， 一 个 大 胆 的 想法 是 将 整个 流程 图 看 成 一 个 stage， 为 最 后 一 个 finalRDD 中 的 每 个 partition 分 
配 一 个 task。 图 示 如 下 : 
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ComplexJob 
including map 由 partitionByQ, unionu, and join 


RDD a ShuffledRDD 
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了 且 和 
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- 
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所 有 的 粗 箭头 组 合成 第 一 个 task， 该 task 计算 结束 后 顺便 将 CoGroupedRDD 中 已 经 计算 得 到 的 第 二 个 和 第 三 个 partition 存 
起 来 。 之 后 第 二 个 task ( 细 实 线 ) 只 需 计 算 两 步 ， 第 三 个 task ( 细 虐 线 ) 也 只 需要 计算 两 步 ， 最 后 得 到 结果 。 


这 个 想法 有 两 个 不 靠 谱 的 地 方 : 


e 第 一 个 task 太 大 ， 磁 到 ShuffleDependency 后 ， 不 得 不 计算 shuffle 依赖 的 RDDs 的 所 有 partitions， 而 且 都 在 这 一 个 
task 里 面 计算 。 
e 需要 设计 巧妙 的 算法 来 判断 哪个 RDD 中 的 哪些 partition 需要 cache。 而 且 cache 会 占用 存储 空间 。 


虽然 这 是 个 不 靠 谱 的 想法 ， 但 有 一 个 可 取 之 处 ， 即 pipeline 思想 : 数据 用 的 时 候 再 算 ， 而 且 数 据 是 流 到 要 计算 的 位 置 的 。 比 
如 在 第 一 个 task 中 ， 从 FlatMappedValuesRDD 中 的 partition 向 前 推算 ， 只 计算 要 用 的 (依赖 的 ) RDDs 及 partitions。 在 
第 二 个 task 中 ， 从 CoGroupedRDD 到 FlatMappedValuesRDD 计算 过 程 中 ， 不 需要 存储 中 间 结 果 (MappedValuesRDD 中 
partition 的 全 部 数据 ) 。 


更 进一步 ， 从 record 粒度 来 讲 ， 如 下 图 中 ， 第 一 个 pattern 中 先 算 g(f(record1))， 然 后 原始 的 record1 和 f(record1) 都 可 以 
丢掉 ， 然 后 再 算 g(f(record2))， 丢 掉 中 间 结 果 ， 最 后 算 g(f(record3))。 对 于 第 二 个 pattern 中 的 g，record1 进入 g 后 ， 理 论 
上 可 以 丢掉 (除非 被 手动 cache) 。 其 他 pattern 同 理 。 
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patterns of record processing 





回 到 stage 和 task 的 划分 问题 ， 上 面 不 靠 谱 想 法 的 主要 问题 是 磋 到 ShuffleDependency 后 无 法 进行 pipeline。 那 么 只 要 在 
ShuffleDependency 你 断 开 ， 就 只 科 NarrowDependency， 而 NarrowDependency chain 是 可 以 进行 pipeline 的 。 按 照 此 思 
想 ， 上 面 ComplexJob 的 划分 图 如 下 : 
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ComplexJob 
including map(, partitionBy0, union(, and join 
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所 以 划分 算法 就 是 : 从 后 往 前 推算 ， 遇 到 ShuffleDependency 就 断 开 ， 遇 到 NarrowDependency 就 将 其 加 入 该 stage。 
每 个 stage 里 面 task 的 数目 由 该 stage 最 后 一 个 RDD 中 的 partition 个 数 决定 。 


粗 箭头 表示 task。 因 为 是 从 后 往 前 推算 ， 因 此 最 后 一 个 stage 的 id 是 0，stage 1 和 stage 2 都 是 stage 0 的 parents。 如 果 
stage 最 后 要 产生 result， 那 么 该 stage 里 面 的 task 都 是 ResultTask， 否 则 都 是 ShuffleMapTask。 之 所 以 称 为 
ShuffleMapTask 是 因为 其 计算 结果 需要 shuffle 到 下 一 个 stage， 本 质 上 相当 于 MapReduce 中 的 mapper。ResultTask 相当 
于 MapReduce 中 的 reducer (如 果 需 要 从 parent stage 那里 shuffle 数据 ) ， 也 相当 于 普通 mapper (如 果 该 stage 没有 
parent stage) 。 


还 有 一 个 问题 : 算法 中 提 到 NarrowDependency chain 可 以 pipeline， 可 是 这 里 的 ComplexJob 只 展示 了 
OneToOneDependency 和 RangeDependency 的 pipeline， 普 通 NarrowDependency 如 何 pipeline ? 


回想 上 一 章 里 面 cartesian(otherRDD) 里 面 复 类 的 NarrowDependency， 图 示 如 下 : 
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a.cartesian(b) Example of a.cartesian(b) 


RDD a CartesianRDD RDD a CartesianRDD 


(1, a), (1, A) 
(2, b), (1, A) 


(1, a), (2, B) 
(2, b), (2, B) 


(3, c), (1, A) 
(4, d), (1, A) 





Stage 0 (6 ResultTasks) a.cartesianilb) 


Data blocks 1 LartesianRDD 


Data blocks 2 





ee ee a ee ee es 


中 粗 箭头 展示 了 第 一 个 ResultTask， 其 他 的 task 依 此 类 推 。 由 于 该 stage 的 task 直接 输出 result， 所 以 这 个 图 包含 6 个 
ResultTasks。 与 OneToOneDependency 不 同 的 是 这 里 每 个 ResultTask 需要 计算 3 个 RDD， 读 取 两 个 data block， 而 整个 
读 取 和 计算 这 三 个 RDD 的 过 程 在 一 个 task 里 面 完 成 。 当 计算 CartesianRDD 中 的 partition 时 ， 需 要 从 两 个 RDD 获取 
records， 由 于 都 在 一 个 task 里 面 ， 不 需要 shuffle。 这 个 图 说 明 : 不 管 是 1:1 还 是 N:1 的 NarrowDependency， 只 要 是 
NarrowDependency chain， 就 可 以 进行 pipeline， 生 成 的 task 个 数 与 该 stage 最 后 一 个 RDD 的 partition 个 数 相同 。 
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物理 图 的 执行 


生成 了 stage 和 task 以 后 ， 下 一 个 问题 就 是 task 如 何 执行 来 生成 最 后 的 result ? 


回 到 ComplexJob 的 物理 执行 图 ， 如 果 按 照 MapReduce 的 逻辑 ， 从 前 到 后 执行 ，map() 产生 中 间 数 据 map outpus， 经 过 


partition 后 放 到 本 地 和 磁盘。 再 经 过 shuffle-sort-aggregate 后 生成 reduce inputs， 最 后 reduce() 执行 得 到 result。 执行 流程 如 
下 : 


map outputs 
Data blocks =<, V> 
reduce inputs 
KK, [lIst<V >> Reeulte 
reducen 





整个 执行 流程 没有 问题 ， 但 不 能 直接 套用 在 Spark 的 物理 执行 图 上 ， 因 为 MapReduce 的 流程 图 简单 、 固 定 ， 而 且 没有 
pipeline。 


回想 pipeline 的 思想 是 数据 用 的 时 候 再 算 ， 而 且 数 据 是 流 到 要 计算 的 位 置 的 。Result 产生 的 地 方 的 就 是 要 计算 的 位 置 ， 要 确 
定 “ 需 要 计算 的 数据 "”， 我 们 可 以 从 后 往 前 推 ， 需 要 哪个 partition 就 计算 哪个 partition， 如 果 partition 里 面 没 有 数据 ， 就 继续 
向 前 推 ， 形 成 computing chain。 这 样 推 下 去 ， 结 果 就 是 : 需要 首先 计算 出 每 个 stage 最 左边 的 RDD 中 的 某 些 partition。 


对 于 没有 parent stage 的 stage， 该 stage 最 左边 的 RDD 是 可 以 立即 计算 的 ， 而 且 每 计算 出 一 个 record 后 便 可 以 流入 
或 g ( 见 前 面 图 中 的 patterns) 。 如 果 f 中 的 record 关系 是 1:1 的 ， 那 么 f(record1) 计算 结果 可 以 立即 顺 着 computing 
chain 流入 g 中。 如果 f 的 record 关系 是 N:1，record1 进入 f0 后 也 可 以 被 回收 。 总 结 一 下 ，computing chain 从 后 到 前 建 
立 ， 而 实际 计算 出 的 数据 从 前 到 后 流动 ， 而 且 计 算出 的 第 一 个 record 流动 到 不 能 再 流动 后 ， 再 计算 下 一 个 record。 这 样 ， 虽 
然 是 要 计算 后 续 RDD 的 partition 中 的 records， 但 并 不 是 要 求 当 前 RDD 的 partition 中 所 有 records 计算 得 到 后 再 整体 向 后 


流动 。 


对 于 有 parent stage 的 stage， 先 等 着 所 有 parent stages 中 final RDD 中 数据 计算 好 ， 然 后 经 过 shuffle 后 ， 问 题 就 又 回 到 
了 计算 “没有 parent stage 的 stage”。 


代码 实现 : 每 个 RDD 包含 的 getDependency( 负责 确立 RDD 的 数据 依赖 ，compute() 方法 负责 接收 parent RDDs 
或 者 data block 流入 的 records， 进 行 计算 ， 然 后 输出 record。 经 常 可 以 在 RDD 中 看 到 这 样 的 代 

码 firstparent[T].iterator(split，context).map(f) 。firstParent 表示 该 RDD 依赖 的 第 一 个 parent RDD，iterator( 表 
示 parentRDD 中 的 records 是 一 个 一 个 流入 该 RDD 的 ，map(f) 表示 每 流入 一 个 recod 就 对 其 进行 f(record) 操作 ， 输 
出 record。 为 了 统一 接口 ， 这 上段 compute() 仍然 返回 一 个 iterator， 来 迭代 map(f) 输出 的 records。 


总 结 一 下 : 整个 computing chain 根据 数据 依赖 关系 自 后 向 前 建立 ， 遇 到 ShuffleDependency 后 形成 stage。 在 每 个 
stage 中 ， 六 RDD 中 的 compute() 调用 parentRDD.iter() 来 将 parent RDDs 中 的 records 一 个 个 fetch 过 来 。 


如 果 要 自己 设计 一 个 RDD， 那 么 需要 注意 的 是 compute() 只 负责 定义 parent RDDs => output records 的 计算 逮 辑 ， 具 体 依 
赖 哪些 parent RDDs 由 getpependency() 定义 ， 上 有 具体 依赖 parent RDD 中 的 哪些 partitions 由 dependency.getParents() 定 
> 


例如 ， 在 CartesianRDD 中 ， 
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// RDD x = (RDD a).cartesian(RDD b) 
// 定义 RDD x 应 该 包含 多 少 个 partition， 每 个 partition 是 什么 类 型 
override def getPartitions: Array[Partition] = { 
// create the cross product split 
val array = new Array[Partition](rddi1.partitions.size * rdd2.partitions.size) 
for (si <- rddi.partitions; s2 <- rdd2.partitions) { 
val idx = si.index * numPartitionsInRdd2 + s2.index 


array(idx) = new Cartesianpartition(idx, rddi, rdd2, si1.index, 


b 


array 


} 


// 定义 RDD x 中 的 每 个 partition 怎么 计算 得 到 


override def compute(split: Partition, context: TaskContext) = { 


val currSplit = split.asInstanceOf[Cartesianpartition] 
// S1 表示 RDD x 中 的 partition 依赖 RDD a 中 的 partitions (这 里 只 依赖 一 个 ) 
// s2 表示 RDD x 中 的 partition 依赖 RDD b 中 的 partitions (这 里 只 依赖 一 个 ) 
for (x <- rddi.iterator(currSplit.s1i, context); 

y <- rdd2.iterator(currSplit.s2, context)) yield (x, y) 


// 定义 RDD x 中 的 partition 工 依赖 于 哪些 RDD 中 的 哪些 partitions 


// 这 里 RDD x 依赖 于 RDD a， 同 时 依赖 于 RDD b， 都 是 NarrowDependency 


// 对 于 第 一 个 依赖 ，RDD x 中 的 partition i 依赖 于 RDD a 中 的 


VM 第 List(i / numPartitionsInRdd2) 个 partition 
// 对 于 第 二 个 依赖 ，RDD x 中 的 partition i 依赖 于 RDD b 中 的 
jy 第 List(id % numPartitionsInRdd2) 个 partition 


override def getDependencies: Seq[Dependency[_|1|] = List( 
new NarrowDependency(rdd1) { 


def getParents(id: 
}, 


new NarrowDependency(rdd2) { 


def getParents(id: 


} 
) 


生成 job 


s2.index) 


Int): Seq[Int]|] = List(id / numPartitionsInRdd2 ) 


Int): Seq[Int|] = List(id % numPartitionsInRdd2 ) 


前 面 介绍 了 逻辑 和 物理 执行 图 的 生成 原理 ， 那 么 ， 怎 么 触发 job 的 生成 ?已 经 介绍 了 task， 那 么 job 是 什么 ? 


下 表 列 出 了 可 以 触发 执行 图 生成 的 典型 action()， 其 中 第 二 列 是 processPartition() ， 定 义 如 何 计算 partition 中 的 records 得 
到 result。 第 三 列 是 resultHandler() ， 定 义 如 何 对 从 各 个 partition 收集 来 的 results 进行 计算 来 得 到 最 终结 果 。 


Action 
reduce(func) 


collect() 
count() 
foreach(f) 
take(n) 

first() 
takeSamplel() 


takeOrdered(n, 
[ordering]) 


saveAsHadoopFile(path) 


countByKey() 


finalRDD(records) => result 


(record1, record2) => result, (result, 
record 1) => result 


Array[records] => result 
count(records) => result 
f(records) => result 
record (I<=n) => result 
record 1 => result 


selected records => result 
TopN(records) => result 


records => write(records) 


(K, V) => Map(K, count(K)) 


compute(results) 


(result1, result 2) => result, (result, result 
|) => result 


Array[result] 
sum(result) 

Array[result] 
Array[result] 
Array[result] 


Array[result] 
TopN(results) 


null 


(Map, Map) => Map(K, count(K)) 


用 户 的 driver 程序 中 一 旦 出 现 action()， 就 会 生成 一 个 job， 上 比如 foreach() 会 调用 sc.runJob(this, (iter: Iterator[T]) => 
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iter.foreach(f)) ， 向 DAGScheduler 提交 job。 如 果 driver 程序 后 面 还 有 action()， 那 么 其 他 action() 也 会 生成 job 提交 。 
所 以 ，driver 有 多 少 个 action()， 就 会 生成 多 少 个 job。 这 就 是 Spark 称 driver 程序 为 application (可 能 包含 多 个 job) 而 不 
是 job 的 原因 。 


每 一 个 job 包含 n 个 stage， 最 后 一 个 Stage 产生 result。 比 如 ， 第 一 章 的 GroupByTest 例子 中 存在 两 个 job， 一 共产 生 了 两 
组 result。 在 提交 job 过 程 中 ，DAGScheduler 会 首先 划分 stage， 然 后 先 提交 无 parent stage 的 stages， 并 在 提交 过 程 中 


确定 该 stage 的 task 个 数 及 类 型 ， 并 提交 具体 的 task。 无 parent stage 的 stage 提交 完 后 ， 依 赖 该 stage 的 stage 才能 够 
提交 。 从 stage 和 task 的 执行 角度 来 讲 ， 一 个 stage 的 parent stages 执行 完 后 ， 该 stage 才能 执行 。 


提交 job 的 实现 细节 


下 面 简 单 分 析 下 job 的 生成 和 提交 代码 ， 提 交 过 程 在 Architecture 那 一 章 也 会 有 图 文 并 成 的 分 析 : 


1. rdd.action() 会 调用 pAGscheduler.runJob(rdd，processPartition，resultHandler) 来 生成 job。 
2. runJob() 会 首先 通过 rdd.getPartitions() 来 得 到 finalRDD 中 应 该 存在 的 partition 的 个 数 和 类 型 : Array[Partition]。 然 后 


根据 partition 个 数 new 出 来 将 来 要 持 有 result 的 数组 Array[Result](partitions.size) 。 

3. 最 后 调用 DAGScheduler 的 runJob(rdd，cleanedFunc，partitions，allowLocal，resultHandler) 来 提交 job。cleanedFunc 
是 processParittion 经 过 闭 包 清理 后 的 结果 ， 这 样 可 以 被 序列 化 后 传递 给 不 同 节点 的 task。 

4. DAGScheduler 的 runJob 继续 调用 submitJob(rdd，func，partitions，allowLocal，resultHandler) 来 提交 job。 

5.，submitJob() 首先 得 到 一 个 jobld， 然 后 再 次 包装 func， 向 DAGSchedulerEventProcessActor 发 送 JobSubmitted 信息 ， 
该 actor 收 到 信息 后 进一步 调用 dagScheduler .handleJobSubmitted() 来 处 理 提交 的 Job。 之 所 以 这 人 么 麻烦 ， 是 为 了 符合 事 
件 驱动 模型 。 

6. handleJobSubmmitted0 首先 调用 finalStage = newStage0 来 划分 stage， 然 后 submitStage(finalStage)。 由 于 
finalStage 可 能 有 parent stages， 实 际 先 提交 parent stages， 等 到 他 们 执行 完 ，finalStage 需要 再 次 提交 执行 。 再 次 提 
交 由 handleJobSubmmitted() 最 后 的 submitWaitingStages() 负责 。 


分 析 一 下 newStage() 如 何 划分 stage : 


1， 该 方法 在 new Stage( 的 时 候 会 调用 finalRDD 的 getParentStages()。 

2. getParentStages() 从 finalRDD 出 发 ， 反 向 visit 远 辑 执行 图 ， 巡 到 NarrowDependency 就 将 依赖 的 RDD 加 入 到 
stage， 过 到 ShuffleDependency 切 开 stage， 并 递归 到 ShuffleDepedency 依赖 的 stage。 

3. 一 个 ShuffleMapStage (不 是 最 后 形成 result 的 stage) 形成 后 ， 会 将 该 stage 最 后 一 个 RDD 注册 
到 | MapoutputTrackerMaster ,registerShuffJle(shuffJleDep.shuffJleId，rdd.partitions.SIze) ， 这 一 步 很 重要 ， 因为 shuffle 过 
程 需要 MapOutputTrackerMaster 来 指示 ShuffleMapTask 输出 数据 的 位 置 。 


分 析 一 下 submitStage(stage) 如 何 提交 stage 和 task : 


1， 先 确定 该 stage 的 missingParentStages， 使 用 getMissingParentstages(stage) 。 如 果 parentStages 都 可 能 已 经 执行 过 
了 ， 那 么 就 为 空 了 。 

2， 如果 missingParentStages 不 为 空 ， 那 么 先 北 为 提交 missing 的 parent stages， 并 将 自己 加 入 到 waitingStages 里 面 ， 
等 到 parent stages 执行 结束 后 ， 会 触发 提交 waitingStages 里 面 的 stage。 

3. 如 果 missingParentStages 为 空 ， 说 明 该 stage 可 以 立即 执行 ， 那 么 就 调用 submitMissingTasks(stage，jobId) 来 生成 和 
是 交 有 具体 的 task。 如 果 stage 是 ShuffleMapStage， 那 么 new 出 来 与 该 stage 最 后 一 个 RDD 的 partition 数 相同 的 
ShuffleMapTasks。 如 果 stage 是 ResultStage， 那 么 new 出 来 与 stage 最 后 一 个 RDD 的 partition 个 数 相同 的 
ResultTasks。 一 个 stage 里 面 的 task 组 成 一 个 TaskSet， 最 后 调用 taskscheduler .submitTasks(taskset) 来 提交 一 整个 
taskSet。 

4. 这 个 taskScheduler 类 型 是 TaskSchedulerImpl， 在 submitTasks() 里 面 ， 每 一 个 taskSet 被 包装 成 manager: 
TaskSetMananger， 然 后 交 给 schedulableBuilder .addTasksetManager (manager) 。 SchedulableBuilder 可 以 是 
FIFOSchedulableBuilder 或 者 FairSchedulableBuilder 调度 器 。submitTasks() 最 后 一 步 是 通 
知 backend.reviveoffers() 去 执行 task，backend 的 类 型 是 SchedulerBackend。 如 果 在 集群 上 运行 ， 那 么 这 个 backend 
类 型 是 SparkDeploySchedulerBackend。 

5. SparkDeploySchedulerBackend 是 CoarseGrainedSchedulerBackend 的 子 类 ， backend.reviveoffers() 其 实 是 向 
DriverActor 发 送 ReviveOffers 信息 。SparkDeploySchedulerBackend 在 start( 的 时 候 ， 会 启动 DriverActor。 
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DriverActor 收 到 ReviveOffers 消息 后 ， 会 调用 launchTasks(scheduler.resourceoffers(Seq(new Workeroffer (executorId, 
executorHost(executorId)，freecores(executorId))))) 来 launch tasks。scheduler 就 是 
TaskSchedulerlImpl。 scheduler.resourceoffers() 从 FIFO 或 者 Fair 调度 器 那里 获得 排序 后 的 TaskSetManager， 并 经 
过 TaskschedulerImpl.resourceoffer() ， 考 虑 locality 等 因素 来 确定 task 的 全 部 信息 TaskDescription。 调 度 细节 这 里 暂 
个 讨论 。 

6. DriverActor 中 的 launchTasks() 将 每 个 task 序列 化 ， 如 果 序 列 化 大 小 不 超过 Akka 的 akkaFrameSize， 那 么 直接 将 task 


送 到 executor 那里 执行 executorActor(task.executorId) ! LaunchTask(new SerializableBuffer(serializedTask)).。 


Discussion 


至 此 ， 我 们 讨论 了 : 


e driver 程序 如 何 触发 job 的 生成 

e 如 何 从 逻辑 执行 图 得 到 物理 执行 图 
e pipeline 思想 与 实现 

e 生成 与 提交 job 的 实际 代码 


还 有 很 多 地 方 没有 深入 讨论 ， 如 : 


e。 连接 stage 的 shuffle 过 程 
e task 运行 过 程 及 运行 位 置 


下 一 章 重 点 讨论 shuffle 过 程 。 


从 逻辑 执行 图 的 建立 ， 到 将 其 转换 成 物理 执行 图 的 过 程 很 经 典 ， 过 程 中 的 dependency 划分 ，pipeline，stage 分 割 ，task 生 
成 都 是 有 条 不 类， 有 理 有 据 的 。 


ComplexJob 的 源 代 码 


package internals 


Import org.apache.spark.SparkContext 
import org.apache.spark.SparkContext._ 
import org.apache.spark.HashPartitioner 


object complexJob { 
def main(args: Array[String]) { 


val sc = new SparkContext("local", "ComplexJob test") 


val datai1 = Array[(Int, Char)]( 
(1 a0)7.(2 50) 
(Se (4 0 ) 
(Se ) (7 1 ) 
(2 UL 
val rangePairs1 = sc.parallelize(datai, 3) 


val hashPairs1 = rangePairs1.partitionBy(new HashPartitioner(3) ) 

val data2 = Array[(Int, String)]((1, "A"), (2, "B"), 
(3 

val pairs2 = sc.parallelize(data2, 2) 


val rangePairs2 = pairs2.map(x => (x._1, x._2.charAt(0))) 


val data3 = Array[(Int, Char)]((1, 'Xx'), (2, 'Y')) 
val rangePairs3 = sc.parallelize(data3, 2) 
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val rangePairs = rangePairs2.union(rangePairs3) 


val result = hashPairs1.]join(rangePairs) 
result.foreachwith(i => i)((x, i) => println("[result "+ i+"] "+ x)) 


printJln(result.toDebugString ) 
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Shuffle 过 程 


上 一 章 里 讨论 了 job 的 物理 执行 图 ， 也 讨论 了 流入 RDD 中 的 records 是 怎么 被 compute( 后 流 到 后 续 RDD 的 ， 同 时 也 分 析 
了 task 是 怎么 产生 result， 以 及 result 怎么 被 收集 后 计算 出 最 终结 果 的 。 然 而 ， 我 们 还 没有 讨论 数据 是 怎么 通过 
ShuffleDependency 流向 下 一 个 stage 的 ? 


对 比 Hadoop MapReduce 和 Spark 的 Shuffle 过 程 


如 果 熟 悉 Hadoop MapReduce 中 的 shuffle 过 程 ， 可 能 会 按照 MapReduce 的 思路 去 想象 Spark 的 shuffle 过 程 。 然 而 ， 它 
们 之 间 有 一 些 区 别 和 联系 。 


从 high-level 的 角度 来 看 ， 两 者 并 没有 大 的 差别 。 都 是 将 mapper (Spark 里 是 ShuffleMapTask) 的 输出 进行 partition， 不 
同 的 partition 送 到 不 同 的 reducer (Spark 里 reducer 可 能 是 下 一 个 stage 里 的 ShuffleMapTask， 也 可 能 是 ResultTask) 。 
Reducer 以 内 存 作 缓冲 区 ， 边 shuffle 边 aggregate 数据 ， 等 到 数据 aggregate 好 以 后 进行 reduce() (Spark 里 可 能 是 后 续 
的 一 系列 操作 ) 。 


从 low-level 的 角度 来 看 ， 两 者 差别 不 小 。 Hadoop MapReduce 是 sort-based， 进 入 combine() 和 reduce( 的 records 必 
须 先 sort。 这 样 的 好 处 在 于 combine/reduce() 可 以 处 理 大 规模 的 数据 ， 因 为 其 输入 数据 可 以 通过 外 排 得 到 (mapper 对 每 段 
数据 先 做 排序 ，reducer 的 shuffle 对 排 好 序 的 每 段 数 据 做 归并 ) 。 目 前 的 Spark 默认 选择 的 是 hash-based， 通 常 使 用 
HashMap 来 对 shuffle 来 的 数据 进行 aggregate， 不 会 对 数据 进行 提前 排序 。 如 果 用 户 需 要 经 过 排序 的 数据 ， 那 么 需要 自己 
调用 类 似 sortByKey 的 操作 ; 如 果 你 是 Spark 1.1 的 用 户 ， 可 以 将 spark.shuffle.manager 设 置 为 sort， 则 会 对 数据 进行 排 
序 。 在 Spark 1.2 中 ，sort 将 作为 默认 的 Shuffle 实 现 。 


从 实现 角度 来 看 ， 两 者 也 有 不 少 差别 。 Hadoop MapReduce 将 义理 流程 划分 出 明显 的 几 个 阶段 : map(), spill, merge， 
shuffle, sort, reduce() 等 。 每 个 阶段 各 司 其 职 ， 可 以 按照 过 程式 的 编程 思想 来 逐一 实现 每 个 阶段 的 功能 。 在 Spark 中 ， 没 有 
这 样 功 能 明确 的 阶段 ， 只 有 不 同 的 stage 和 一 系列 的 transformation()， 所 以 spill, merge, aggregate 等 操作 需要 瘟 含 在 
transformation() 中 。 


如 果 我 们 将 map 端 划 分 数据 、 持 久 化 数据 的 过 程 称 为 shuffle write， 而 将 reducer 读 入 数据 、aggregate 数据 的 过 程 称 为 


shuffle read。 那 么 在 Spark 中 ， 问 题 就 变 为 怎么 在 job 的 逻辑 或 者 物理 执行 图 中 加 入 shuffle write 和 shuffle read 的 处 理 
逻辑 ?以 及 两 个 处 理 远 辑 应 该 怎么 高 效 实现 ? 


Shuffle write 


由 于 不 要 求 数据 有 序 ，shuffle write 的 任务 很 简单 : 将 数据 partition 好 ， 并 持久 化 。 之 所 以 要 持久 化 ， 一 方面 是 要 减少 内 存 
存储 空间 压力 ， 另 一 方面 也 是 为 了 fault-tolerance。 


shuffle write 的 任务 很 简单 ， 那 么 实现 也 很 简单 : 将 shuffle write 的 义理 逻辑 加 入 到 ShuffleMapStage (ShuffleMapTask 所 
在 的 stage) 的 最 后 ， 该 stage 的 final RDD 每 输出 一 个 record 就 将 其 partition 并 持久 化 。 图 示 如 下 : 
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Shuffle write in Worker Node ( 2 cores, 4 ShuffleMap Tasks, 3 reducers, consolidateFiles = false ) 
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上 图 有 4 个 ShuffleMapTask 要 在 同一 个 worker node 上 运行 ，CPU core 数 为 2， 可 以 同时 运行 两 个 task。 每 个 task 的 执 
行 结果 (该 stage 的 finalRDD 中 某 个 partition 包含 的 records) 被 逐一 写 到 本 地 磁盘 上 。 每 个 task 包含 R 个 缓冲 区 ，R = 
reducer 个 数 (也 就 是 下 一 个 stage 中 task 的 个 数 ) ， 缓 冲 区 被 称 为 bucket， 其 大 小 为 spark.shuffle.file.buffer.kb ， 默 
认 是 32KB (Spark 1.1 版 本 以 前 是 100KB) 。 


其 实 bucket 是 一 个 广义 的 概念 ， 代 表 ShuffleMapTask 输出 结果 经 过 partition 后 要 存放 的 地 方 ， 这 里 为 了 细 化 数据 存 
放 位 置 和 数据 名 称 ， 仅 仅 用 bucket 表示 缓冲 区 。 


ShuffleMapTask 的 执行 过 程 很 简单 : 先 利用 pipeline 计算 得 到 finalRDD 中 对 应 partition 的 records。 每 得 到 一 个 record 就 
将 其 送 到 对 应 的 bucket 里 ， 上 有 具体 是 哪个 bucket 由 partitioner.partition(record.getkey())) 决定 。 每 个 bucket 里 面 的 数据 
会 不 断 被 写 到 本 地 磁盘 上 ， 形 成 一 个 ShuffleBlockFile， 或 者 简称 FileSegment。 之 后 的 reducer 会 去 fetch 属于 自己 的 
FileSegment， 进 入 shuffle read 阶段 。 


这 样 的 实现 很 简单 ， 但 有 几 个 问题 : 


1. 产生 的 FileSegment 过 多 。 每 个 ShuffleMapTask 产生 R (reducer 个 数 ) 个 FileSegment，M 个 ShuffleMapTask 就 会 
产生 M* RR 个 文件 。 一 般 Spark job 的 M 和 R 都 很 大 ， 因 此 磁盘 上 会 存在 大 量 的 数据 文件 。 

2. 缓冲 区 占用 内 存 空间 大 。 每 个 ShuffleMapTask 需要 开 R 个 bucket，M 个 ShuffleMapTask 就 会 产生 M 尺 个 bucket 虽 
然 一 个 ShuffleMapTask 结束 后 ， 对 应 的 缓冲 区 可 以 被 回收 ， 但 一 个 worker node 上 同时 存在 的 bucket 个 数 可 以 达到 
coresR 个 一般 worker 同时 可 以 运行 cores 个 ShuffleMapTask) ， 占 用 的 内 存 空 间 也 就 达到 了 cores * R * 32 KB 。 
对 于 8 核 1000 个 reducer 来 说 ， 占 用 内 存 就 是 256MB。 


目前 来 看 ， 第 二 个 问题 还 没有 好 的 方法 解决 ， 因 为 写 人 磁盘 终 究 是 要 开 缓 冲 区 的 ， 缓 冲 区 太 小 会 影响 IO 速度。 但 第 一 个 问题 
有 一 些 方法 去 解决 ， 下 面 介 绍 已 经 在 Spark 里 面 实现 的 FileConsolidation 方法 。 先 上 图 : 
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Shuffle write in Worker Node ( 2 cores, 4 ShuffleMapTasks, 3 reducers, consolidateFiles = true ) 
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可 以 明显 看 出 ， 在 一 个 core 上 连续 执行 的 ShuffleMapTasks 可 以 共用 一 个 输出 文件 ShuffleFile。 先 执行 完 的 
ShuffleMapTask 形成 ShuffleBlock i， 后 执行 的 ShuffleMapTask 可 以 将 输出 数据 直接 追加 到 ShuffleBlock i 后 面 ， 形 成 
ShuffleBlock ii， 每 个 ShuffleBlock 被 称 为 FileSegment。 下 一 个 stage 的 reducer 只 需要 fetch 整个 ShuffleFile 就 行 了 。 这 
样 ， 每 个 worker 持 有 的 文件 数 降 为 cores * R。FileConsolidation 功能 可 以 通过 spark.shuffle.consolidateFiles=true 来 开 
后 。 


Shuffle read 


先 看 一 张 包含 ShuffleDependency 的 物理 执行 图 ， 来 自 reduceByKey : 
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reduceByKey(f, numPartitions) 
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Stage 0 (2 ResultTasks) 


Example (WordCount): reduceByKey(_ + _, 2) 
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很 自然 地 ， 要 计算 ShuffleRDD 中 的 数据 ， 必 须 先 把 MapPartitionsRDD 中 的 数据 fetch 过 来 。 那 么 问题 就 来 了 : 


e 在 什么 时 候 fetch，parent stage 中 的 一 个 ShuffleMapTask 执行 完 还 是 等 全 部 ShuffleMapTasks 执行 完 ? 
e。 边 fetch 边 处 理 还 是 一 次 性 fetch 完 再 处 理 ? 

e。 fetch 来 的 数据 存放 到 哪里 ? 

e@ 怎么 获得 要 fetch 的 数据 的 存放 位 置 ? 


解决 问题 : 


e 在 什么 时 候 fetch ? 当 parent stage 的 所 有 ShuffleMapTasks 结束 后 再 fetch。 理 论 上 讲 ， 一 个 ShuffleMapTask 结束 后 
就 可 以 fetch， 但 是 为 了 迎合 stage 的 概念 〈 即 一 个 stage 如 果 其 parent stages 没有 执行 完 ， 自 己 是 不 能 被 提交 执行 
的 ) ， 还 是 选择 全 部 ShuffleMapTasks 执行 完 再 去 fetch。 因 为 fetch 来 的 FileSegments 要 先 在 内 存 做 缓冲 ， 所 以 一 次 
fetch 的 FileSegments 总 大 小 不 能 太 大 。Spark 规定 这 个 缓冲 界限 不 能 超过 spark.reducer.maxMbInFlight ， 这 里 用 
softBuffer 表示 ， 默 认 大 小 为 48MB。 一 个 softBuffer 里 面 一 般 包含 多 个 FileSegment， 但 如 果 某 个 FileSegment 特别 
大 的 话 ， 这 一 个 融 可 以 填 满 甚至 超过 softBuffer 的 界限 。 

e@ 边 fetch 边 处 理 还 是 一 次 性 fetch 完 再 处 理 ? 边 fetch 边 处 理 。 本 质 上 ，MapReduce shuffle 阶段 就 是 边 fetch 边 使 用 
combine() 进行 处 理 ， 只 是 combine() 处 理 的 是 部 分 数据 。MapReduce 为 了 让 进入 reduce( 的 records 有 序 ， 必 须 等 到 
全 部 数据 都 shuffle-sort 后 再 开始 reduce()。 因 为 Spark 不 要 求 shuffle 后 的 数据 全 局 有 序 ， 因 此 没 必要 等 到 全 部 数据 
shuffle 完成 后 再 人 处理。 那么 如 何 实现 边 shuffle 边 处 理 ， 而 且 流 入 的 records 是 无 序 的 ?答案 是 使 用 可 以 aggregate 的 
数据 结构 ， 比 如 HashMap。 每 shuffle 得 到 (从 缓冲 的 FileSegment 中 deserialize 出 来 ) 一 个 \record， 直 接 将 其 放 进 
HashMap 里 面 。 如 果 该 HashMap 已 经 存在 相应 的 Key， 那 么 直接 进行 aggregate 也 就 是 func(hashMap.get (Key)， 
value) ， 上 比如 上 面 WordCount 例子 中 的 func 就 是 hashMap.get(Key) + value ， 并 将 func 的 结果 重新 put(key) 到 
HashMap 中 去 。 这 个 func 功能 上 相当 于 reduce()， 但 实际 处 理 数据 的 方式 与 MapReduce reduce() 有 差别 ， 差 别 相当 
于 下 面 两 段 程序 的 差别 。 


// MapReduce 
reduce(K key, Iterable<V> values) { 
result = process(key, values) 
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return result 


} 


// Spark 
reduce(K key, Iterable<V> values) { 
result = null 
for (V value : values) 
result = func(result, value) 
return result 


MapReduce 可 以 在 process 加 数 里 面 可 以 定义 任何 数据 结构 ， 也 可 以 将 部 分 或 全 部 的 values 都 cache 后 再 进行 处 理 ， 
非常 灵活 。 而 Spark 中 的 func 的 输入 参数 是 固定 的 ， 一 个 是 上 一 个 record 的 处 理 结 果 ， 另 一 个 是 当前 读 入 的 record， 
它们 经 过 func 义理 后 的 结果 被 下 一 个 record 处 理 时 使 用 。 因 此 一 些 算法 比如 求 平均 数 ， 在 process 里 面 很 好 实现 ， 直 
接 sum(values)/values.length ， 而 在 Spark 中 func 可 以 实现 sum(values) ， 但 不 好 实现 /values.length 。 更 多 的 func 将 
会 在 下 面 的 章节 细致 分 析 。 


e fetch 来 的 数据 存放 到 哪里 ? 刚 fetch 来 的 FileSegment 存放 在 softBuffer 缓冲 区 ， 经 过 处 理 后 的 数据 放 在 内 存 + 磁盘 
上 。 这 里 我 们 主要 讨论 人 处理 后 的 数据 ， 可 以 灵活 设置 这 些 数 据 是 “只 用 内 存 " 还 是 “内 存 十 磁 意 ”"。 如 果 spark.shuffle.spill 
= false 就 只 用 内 存 。 内 存 使 用 的 是 AppendonlyMap ， 类 似 Java 的 HashMap ， 内 存 十 磁盘 使 用 的 
是 ExternalAppendonlyMap， 如 果 内 存 空间 不 足 时 ， ExternalAppendonlyMap 可 以 将 \records 进行 sort 后 spill 到 人 矿 盘 上 ， 
等 到 需要 它们 的 时 候 再 进行 为 并 ， 后 面 会 详解 。 使 用 “内 存 十 磁盘 ”的 一 个 主要 问题 就 是 如 何在 两 者 之 间 取 得 平衡 ?在 
Hadoop MapReduce 中 ， 黑 认 将 reducer 的 70% 的 内 存 空 间 用 于 存放 shuffle 来 的 数据 ， 等 到 这 个 空间 利用 率 达 到 
66% 的 时 候 就 开始 merge-combine()-spill。 在 Spark 中 ， 也 适用 同样 的 策略 ， 一 旦 ExternalAppendOnlyMap 达到 一 个 
阅 值 就 开始 spill， 上 县 体 细节 下 面 会 讨论 。 

e 怎么 获得 要 fetch 的 数据 的 存放 位 置 ?在 上 一 章 讨 论 物 理 执行 图 中 的 stage 划分 的 时 候 ， 我 们 强调 “一 个 
ShuffleMapStage 形成 后 ， 会 将 该 stage 最 后 一 个 final RDD 注册 到 MapoutputTrackerMaster.registershuffle(shufflerd, 
rdd.partitions.size) ， 这 一 步 很 重要 ， 因 为 shuffle 过 程 需要 MapOutputTrackerMaster 来 指示 ShuffleMapTask 输出 数 
据 的 位 置 ?。 因 此 ，reducer 在 shuffle 的 时 候 是 要 去 driver 里 面 的 MapOutputTrackerMaster 询问 ShuffleMapTask 输出 
的 数据 位 置 的 。 每 个 ShuffleMapTask 完成 时 会 将 FileSegment 的 存储 位 置信 息 汇报 给 MapOutputTrackerMaster。 


至 此 ， 我 们 已 经 讨论 了 shuffle write 和 shuffle read 设计 的 核心 思想 、 算 法 及 某 些 实现 。 接 下 来 ， 我 们 深入 一 些 细 节 来 讨 
论 5 


典型 transformation() 的 shuffle read 


1. reduceByKey(func) 


上 面 初步 介 绍 了 reduceByKey() 是 如 何 实现 边 fetch 边 reduce() 的 。 需 要 注意 的 是 虽然 Example(WordCount) 中 给 出 了 各 个 
RDD 的 内 容 ， 但 一 个 partition 里 面 的 records 并 不 是 同时 存在 的 。 比 如 在 ShuffledRDD 中 ， 每 fetch 来 一 个 record 就 立即 
进入 了 func 进行 处 理 。MapPartitionsRDD 中 的 数据 是 func 在 全 部 records 上 的 处 理 结果 。 从 record 粒度 上 来 看 ，reduce() 
可 以 表示 如 下 : 
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ShuffledRDD MapPartitionsRDD 
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可 以 看 到 ，fetch 来 的 records 被 逐个 aggreagte 到 HashMap 中 ， 等 到 所 有 records 都 进入 HashMap， 就 得 到 最 后 的 义理 
结果 。 唯 一 要 求 是 func 必须 是 commulative 的 (参见 上 面 的 Spark 的 reduce() 的 代码 ) 。 


ShuffledRDD 到 MapPartitionsRDD 使 用 的 是 mapPartitionsWithContext 操作 。 


为 了 减少 数据 传输 量 ，MapReduce 可 以 在 map 端 先 进行 combine()， 其 实在 Spark 也 可 以 实现 ， 只 需要 将 上 图 
ShuffledRDD => MapPartitionsRDD 的 mapPartitionsWithContext 在 ShuffleMapStage 中 也 进行 一 次 即 可 ， 上 比如 
reduceByKey 例子 中 ParallelCollectionRDD => MapPartitionsRDD 完成 的 就 是 map 端的 combine()。 


对 比 MapReduce 的 map()-reduce() 和 Spark 中 的 reduceByKey() : 


e map 端的 区 别 : map0 没有 区 别 。 对 于 combine()，MapReduce 先 sort 再 combine()，Spark 直接 在 HashMap 上 进行 
combine()。 

e reduce 端 区 别 : MapReduce 的 shuffle 阶段 先 fetch 数据 ， 数 据 量 到 达 一 定 规模 后 combine()， 再 将 剩余 数据 merge- 
sort 后 reduce()，reduce() 非常 灵活 。Spark 边 fetch 边 reduce() (在 HashMap 上 执行 func) ， 因 此 要 求 func 符合 
commulative 的 特性 。 


从 内 存 利用 上 来 对 比 : 


e map 端 区 别 : MapReduce 需要 开 一 个 大 型 环形 缓冲 区 来 暂 存 和 排序 map() 的 部 分 输出 结果 ， 但 combine() 不 需要 额外 
空间 (除非 用 户 自己 定义 ) 。 Spark 需要 HashMap 内 存 数据 结构 来 进行 combine()， 同 时 输出 records 到 磁盘 上 时 也 
需要 一 个 小 的 buffer (bucket) 。 

e reduce 端 区 别 : MapReduce 需要 一 部 分 内 存 空间 来 存储 shuffle 过 来 的 数据 ，combine() 和 reduce( 不 需要 额外 空间 ， 
因为 它们 的 输入 数据 分 段 有 序 ， 只 需 为 并 一 下 就 可 以 得 到 。 在 Spark 中 ，fetch 时 需要 softBuffer， 钦 理 数据 时 如 果 只 使 
用 内 存 ， 那 么 需要 HashMap 来 持 有 处理 后 的 结果 。 如 果 使 用 内 存 十 人 磁 意 ， 那 么 在 HashMap 存放 一 部 分 处 理 后 的 数 
据 。 


2. groupByKey(numPartitions) 


Shuffle 过 程 42 


Apache Spark 的 设计 和 与 实现 


Example: groupByKeyl2) 


ParallelGollectionRDD ohufttledRDD viapParttionsRDD 
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与 reduceByKey'( 流程 一 样 ， 只 是 func 变 成 result = result ++ record.value ， 功 能 是 将 每 个 key 对 应 的 所 有 values 链接 
在 一 起 。result 来 自 hashMap.get(record.key)， 计 算 后 的 result 会 再 次 被 put 到 hashMap 中 。 与 reduceByKey( 的 区 别 就 
是 groupByKey( 没有 map 端的 combine()。 对 于 groupByKey() 来 说 map 端的 combine() 只 是 减少 了 重复 Key 占用 的 空 
间 ， 如 果 key 重复 率 不 高 ， 没 必要 combine(0， 否 则 ， 最 好 能 够 combine()。 


3. distinct(numPartitions) 


Example: distinct(2) 
- represents ‘null 


I MappedRDD MapPartitionsRDD ShuffledRDD MapPartitionsRDD MappedRDD 





与 reduceByKey() 流程 一 样 ， 只 是 func 变 成 result = result == null? record.value : result ， 如 果 HashMap 中 没有 该 
record 就 将 其 放 入 ， 否 则 舍弃 。 与 reduceByKey() 相同 ， 在 map 端 存在 combine()。 


4. cogroup(otherRDD, numPartitions) 
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Example of acogroupID) 










RDD a a.Partitioner = GoGroupedRDD.Partitioner 
/ = RangePartitioner(3) 
CoGroupedRDOD MappedwaluesRDD 


T,[lterfabj， lter(f)] 


一 2 [lterlcl, lter(hj] 
3, [ltertd), lter(a 


4, [lterte), lterf}] | 


CoGroupedRDD 可 能 有 0 个 、1 个 或 者 多 个 ShuffleDependency。 但 并 不 是 要 为 每 一 个 ShuffleDependency 建立 一 个 
HashMap， 而 是 所 有 的 Dependency 共用 一 个 HashMap。 与 reduceByKey( 不 同 的 是 ，HashMap 在 CoGroupedRDD 的 
compute() 中 建立 ， 而 不 是 在 mapPartitionsWithContext( 中 建立 。 


粗 线 表示 的 task 首先 new 出 一 个 Array[ArrayBuffer0, ArrayBuffer()]，ArrayBuffer() 的 个 数 与 参与 cogroup 的 RDD 个 数 相 
同 。func 的 逻辑 是 这 样 的 : 每 当 从 RDD a 中 shuffle 过 来 一 个 \record 就 将 其 添加 到 hashmap.get(Key) 对 应 的 Array 中 的 
第 一 个 ArrayBuffer() 中 ， 每 当 从 RDD b 中 shuffle 过 来 一 个 record， 就 将 其 添加 到 对 应 的 Array 中 的 第 二 个 ArrayBuffer()。 


CoGroupedRDD => MappedValuesRDD 对 应 mapValues() 操作 ， 就 是 将 [ArrayBuffer(), ArrayBuffer()] 变 成 [lterable[V]， 
lterable[W]]。 


5. intersection(otherRDD) 和 join(otherRDD, numPartitions) 


Example of a.intersection(b) 


MappPeun - represents ‘null’ 
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ParallelCollectionRDD 1 Example of a.join(b) 
RDD1.partitioner != CoGroupedRDD.partitioner 





MappedValuesRDD FlatMappedValuesRDD 

















4, [it(d), it(D)] 
1, [it(a, h), it(A)] 


4, [(d), (D)] 
1, [(a, h), (A)] 
ParallelCollectionRDB 
5, [(e), ()] 
| 2, [(b, g), (B)] 












5, [it(e), it()] 
2, [it(b, g), it(B)] 





这 两 个 操作 中 均 使 用 了 cogroup， 所 以 shuffle 的 处 理 方式 与 cogroup 一 样 。 


6. sortByKey(ascending, numPartitions) 


Example of sortByKeyitrue, 2) 


ParallelGollectionRDD ohuffledRDD viapParttionsRDD 





sortByKey() 中 ShuffledRDD => MapPartitionsRDD 的 处 理 逻 辑 与 reduceByKey() 不 太一 样 ， 没 有 使 用 HashMap 和 func 来 
处 理 fetch 过 来 的 records。 


sortByKey() 中 ShuffledRDD => MapPartitionsRDD 的 处 理 逻 辑 是 : 将 shuffle 过 来 的 一 个 个 record 存放 到 一 个 Array 里 ， 
然后 按照 Key 来 对 Array 中 的 records 进行 sort。 


7. coalesce(numpPartitions, shuffle = true) 
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Example: a.coalesce(3, shuffle = true) 


MapPartitionsRDD 
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coalesce() 虽然 有 ShuffleDependency， 但 不 需要 对 shuffle 过 来 的 records 进行 aggregate， 所 以 没有 建立 HashMap。 每 
shuffle 一 个 record， 就 直接 流向 CoalescedRDD， 进 而 流向 MappedRDD 中 。 


Shuffle read 中 的 HashMap 


HashMap 是 Spark shuffle read 过 程 中 频繁 使 用 的 、 用 于 aggregate 的 数据 结构 。Spark 设计 了 两 种 : 一 种 是 全 内 存 的 
AppendOnlyMap， 另 一 种 是 内 存 十 磁盘 的 ExternalAppendOnlyMap。 下 面 我 们 来 分 析 一 下 两 者 特性 及 内 存 使 用 情况 。 


1. AppendOnlyMap 


AppendOnlyMap 的 官方 介绍 是 A simple open hash table optimized for the append-only use case, where keys are never 


= 三 上 昌 旦 


removed, but the value for each key may be changed。 和 总 心 定 


类 似 HashMap， 但 没有 remove(key) 方法 。 其 实现 原理 很 简 


单 ， 开 一 个 大 Object 数组 ， 蓝 色 部 分 存储 Key， 白 色 部 分 存储 Value。 如 下 图 : 


put(K6, V6) 


NN 


hash(k6) hash(k6) + 1*1 


Array[(K, V)] 


| 


hash(k6) 


一 一 


result = get(K6) then put(K6, func(result, Value)) 


hash(k6) + 1*1 


AppendOnlyMap 


hash(k6) + 2*2 


hash(k6) + 2*2 





当 要 put(K, V) 时 ， 先 hash(K) 找 存 放 位 置 ， 如 果 存 放 位 置 已 经 被 占用 ， 就 使 用 Quadratic probing 探测 方法 来 找 下 一 个 空 
闲 位 置 。 对 于 图 中 的 K6 来 说 ， 第 三 次 查找 找到 K4 后 面 的 空闲 位 置 ， 放 进去 即 可 。get(K6) 的 时 候 类 似 ， 找 三 次 找到 K6， 
取出 坚 挨 着 的 V6， 与 先 来 的 value 做 func， 结 果 重 新 放 到 V6 的 位 置 。 
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迭代 AppendOnlyMap 中 的 元 素 的 时 候 ， 从 前 到 后 扫描 输出 。 
如 果 Array 的 利用 率 达 到 70%， 那 么 就 扩张 一 倍 ， 并 对 所 有 key 进行 rehash 后 ， 重 新 排列 每 个 key 的 位 置 。 
AppendOnlyMap 还 有 一 个 destructivesortedIterator(): Iterator[(K，V)] 方法 ， 可 以 返回 Array 中 排序 后 的 (K, V) pairs。 


实现 方法 很 简单 : 先 料 所 有 (K, V) pairs compact 到 Array 的 前 端 ， 并 使 得 每 个 (K, V) 占 一 个 位 置 (原来 占 两 个 ) ， 之 后 直 
接 调 用 Array.sort( 排序 ， 不 过 这 样 做 会 破坏 数组 (key 的 位 置 变化 了 ) 。 


2. ExternalAppendOnlyMap 
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ExternalAppendOnlyMap insert(Ki, Vi) 


AppendOnlyMap / 







sortedMap 


final sorted map 


K2 | K4 K6 
R2 | R4 R6 


destructiveSortedlterator 


mergedBuffers[StreamBuffen] 


minBuffer 
minKeyHash = hash(K1) 
要 minKey = K1 
~ MinCombiner = Ri1 


mergeHeap: PriorityQueue[StreamBuffer] 


suppose hash(K1) = hash(K2) = hash(K3) < hash(K 分 二 hash(K5) merge & combine 


output 


Externallterator.next() R1 





new mergeHeap: PriorityQueue[StreamBuffen] 
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相 比 AppendOnlyMap，ExternalAppendOnlyMap 的 实现 略 复杂 ， 但 逻辑 其 实 很 简单 ， 类 似 Hadoop MapReduce 中 的 
shuffle-merge-combine-sort 过 程 : 


ExternalAppendOnlyMap 持 有 一 个 AppendOnlyMap，shuffle 来 的 一 个 个 (K, V) record 先 insert 到 AppendOnlyMap 中 ， 
insert 过 程 与 原始 的 AppendOnlyMap 一 模 一 样 。 如 果 AppendOnlyMap 快 被 装 满 时 检查 一 下 内 存 剩余 空间 是 否 可 以 够 扩 
展 ， 够 就 直接 在 内 存 中 扩展 ， 不 够 就 sort 一 下 AppendOnlyMap， 将 其 内 部 所 有 records 都 spill 到 磁盘 上 。 图 中 spil 了 4 
次 ， 每 次 spill 完 在 磁盘 上 生成 一 个 spilledMap 文件 ， 然 后 重新 new 出 来 一 个 AppendOnlyMap。 最 后 一 个 (K, V) record 
insert 到 AppendOnlyMap 后 ， 表 示 所 有 shuffle 来 的 records 都 被 放 到 了 ExternalAppendOnlyMap 中 ， 但 不 表示 records 
已 经 被 处 理 完 ， 因 为 每 次 insert 的 时 候 ， 新 来 的 record 只 与 AppendOnlyMap 中 的 records 进行 aggregate， 并 不 是 与 所 有 
的 records 进行 aggregate (一 些 records 已 经 被 spill 到 磁盘 上 了 ) 。 因 此 当 需 要 aggregate 的 最 终结 果 时 ， 需 要 对 
AppendOnlyMap 和 所 有 的 spilledMaps 进行 全 局 merge-aggregate。 


全 局 merge-aggregate 的 流程 也 很 简单 : 先 将 AppendOnlyMap 中 的 records 进行 sort， 形 成 sortedMap。 然后 利用 
DestructiveSortedlterator 和 DiskMaplterator 分 别 从 sortedMap 和 各 个 spilledMap 读 出 一 部 分 数据 (StreamBuffer) 放 到 
mergeHeap 里 面 。StreamBuffer 里 面包 含 的 records 需要 具有 相同 的 hash(key)， 所 以 图 中 第 一 个 spilledMap 只 读 出 前 三 个 
records 进入 StreamBuffer。mergeHeap 顾名思义 融 是 使 用 堆 排 序 不 断 提 取出 hash(firstRecord.Key) 相同 的 

StreamBuffer， 并 将 其 一 个 个 放 和 人 mergeBuffers 中 ， 放 和 的 时 候 与 已 经 存在 于 mergeBuffers 中 的 StreamBuffer 进行 
merge-combine， 第 一 个 被 放 入 mergeBuffers 的 StreamBuffer 被 称 为 minBuffer， 那 么 minKey 就 是 minBuffer 中 第 一 个 
record 的 key。 当 merge-combine 的 时 候 ， 与 minKey 相同 的 records 被 aggregate 一 起 ， 然 后 输出 。 整 个 merge-combine 
在 mergeBuffers 中 结束 后 ，StreamBuffer 剩余 的 records 随 着 StreamBuffer 重新 进入 mergeHeap。 一 旦 某 个 
StreamBuffer 在 merge-combine 后 变 为 空 〈 里 面 的 records 都 被 输出 了 ) ， 那 么 会 使 用 DestructiveSortedlterator 或 
DiskMaplterator 重新 装填 hash(key) 相同 的 records， 然 后 再 重新 进入 mergeHeap。 


整个 insert-merge-aggregate 的 过 程 有 三 点 需要 进一步 探讨 一 下 : 
e 内 存 剩余 空间 检测 


与 Hadoop MapReduce 规定 reducer 中 70% 的 空间 可 用 于 shuffle-sort 类 似 ，Spark 也 规定 executor 中 
spark.shuffle.memoryFraction * spark.shuffle.safetyFraction 的 空间 (默认 是 Ons. Ra) 可 用 于 
ExternalOnlyAppendMap。Spark 略 保守 是 不 是 ? 更 保守 的 是 这 24% 的 空间 不 是 完全 用 于 一 个 
ExternalOnlyAppendMap 的 ， 而 是 由 在 executor 上 同时 运行 的 所 有 reducer 共享 的 。 为 此 ，exectuor 专门 持 有 一 个 
ShuffleMemroyMap: HashMap[threadId，occupiedMemory] 来 监控 每 个 reducer 中 ExternalOnlyAppendMap 占用 的 内 存量 。 
每 当 AppendOnlyMap 要 扩展 时 ， 都 会 计算 ShuffleMemroyMap 持 有 的 所 有 reducer 中 的 AppendOnlyMap 已 占用 的 
内 存 十 扩展 后 的 内 存 是 会 否 会 大 于 内 存 限 制 ， 大 于 就 会 和 择 AppendOnlyMap spill 到 磁盘 。 有 一 点 需要 注意 的 是 前 1000 
个 records 进入 AppendOnlyMap 的 时 候 不 会 启动 是 否 要 spill 的 检查 ， 需 要 扩展 时 融和 直接 在 内 存 中 扩展 。 


e AppendOnlyMap 大 小 估计 


为 了 获知 AppendOnlyMap 占用 的 内 存 空 间 ， 可 以 在 每 次 扩展 时 都 将 AppendOnlyMap reference 的 所 有 objects 大 小 都 
算 一 通 ， 然 后 加 和 ， 但 这 样 做 非常 耗 时 。 所 以 Spark 设计 了 粗略 的 估算 算法 ， 算 法 时 间 复 条 度 是 O(1)， 核 心思 想 是 利用 
AppendOnlyMap 中 每 次 insert-aggregate record 后 result 的 大 小 变化 及 一 共 insert 的 records 的 个 数 来 估算 大 小 ， 具 体 


见 SizeTrackingAppendonlyMap 和 SizeEstimator 。 
e。 Spill 过 程 


与 shuffle write 一 样 ， 在 spill records 到 磁盘 上 的 时 候 ， 会 建立 一 个 buffer 缓冲 区 ， 大 小 仍 为 
spark.shuffle.file.buffer.kb ， 默 认 是 32KB。 另外 ， 由 于 serializer 也 会 分 配 缓冲 区 用 于 序列 化 和 反 序 列 化 ， 所 以 如 
果 一 次 serialize 的 records 过 多 的 话 缓冲 区 会 变 得 很 大 。Spark 限制 每 次 serialize 的 records 个 数 为 
spark.shuffle.spill.batchsize ， 默 认 是 10000。 


DISCUSSIOn 


通过 本 章 的 介绍 可 以 发 现 ， 相 比 MapReduce 固定 的 shuffle-combine-merge-reduce 策略 ，Spark 更 加 有 灵活， 会 根据 不 同 的 
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transformation() 的 语义 去 设计 不 同 的 shuffle-aggregate 策略 ， 再 加 上 不 同 的 内 存 数据 结构 来 混搭 出 合理 的 执行 流程 。 

这 章 主 要 讨论 了 Spark 是 怎么 在 不 排序 records 的 情况 下 完成 shuffle write 和 shuffle read， 以 及 怎么 将 shuffle 过 程 融 入 
RDD computing chain 中 的 。 附 带 讨 论 了 内 存 和 与 磁盘 的 平衡 以 及 与 Hadoop MapReduce shuffle 的 异同 。 下 一 章 将 从 部 署 图 
以 及 进程 通信 和 角度 来 描述 job 执行 的 整个 流程 ， 也 会 涉及 shuffle write 和 shuffle read 中 的 数据 位 置 获取 问题 。 


另外 ，Jerry Shao 写 的 详细 探究 Spark 的 shuffle 实 现 很 先 ， 里 面 还 介绍 了 shuffle 过 程 在 Spark 中 的 进化 史 。 目 前 sort- 
based 的 shuffle 也 在 实现 当中 ，stay tuned。 
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架构 


前 三 章 从 job 的 角度 介绍 了 用 户 写 的 program 如 何 一 步 步 地 被 分 解 和 执行 。 这 一 章 主 要 从 架构 的 角度 来 讨论 master,， 
worker，driver 和 executor 之 间 怎 么 协调 来 完成 整个 job 的 运行 。 


实在 不 想 在 文档 中 贴 过 多 的 代码 ， 这 章 贴 这 么 多 ， 只 是 为 了 方面 自己 回头 debug 的 时 候 可 以 迅速 定位 ， 不 想 看 代码 的 
话 ， 下 搂 看 图 和 挡 述 即 可 。 


部 四 图 


重新 贴 一 下 Overview 中 给 出 的 部 署 图 : 


Worker Node 2 
Master Node 


Worker 


CoarseGrainedExecu 
torBackend 
Driver 
application.main() 
Driver 
application.main() 


Worker Node 1 Worker Node 3 


Worker 


ExecutorRunner ExecutorRunner 


CoarseGrainedExecutorBackend CoarseGrainedExecutorBackend 


CoarseGrainedExecu 
Executor Executor torBackend 
Legend: 
Task Process 


Object 


CoarseGrainedExecu 
torBackend 





接 下 来 分 阶段 讨论 并 细 化 这 个 图 。 


Job 提交 


下 图 展示 了 driver program (假设 在 master node 上 运行 ) 如 何 生成 job， 并 提交 到 worker node 上 执行 。 
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Master Node 


def main() { 
val sc = new SparkContext() 
val rdd = sc.makeRDD() 
val finalRDD = rdd.transformation() 
val result = finalRDD.action() 


} 


sc.runJob!( 


dagScheduler 


六 


eviveOffers() 





aunchTask(serialized Task) 


Driver 端的 逻辑 如 果 用 代码 表示 : 


finalRDD.action() 
=> sc.runJob() 


// generate job, stages and tasks 

=> dagSscheduler.runJob() 

=> dagScheduler.submitJob() 

-=> dagSschedulerEventProcessActor ! JobSubmitted 

=> dagSschedulerEventProcessActor.JobSubmitted() 

=> dagSsScheduler.handleJobSubmitted() 

=> finalStage = newStage'( ) 

=> mapOutputTracker.registerShuffle(shuffleId, rdd.partitions.size) 
=> dagSsScheduler.submitStage() 

> missingStages = dagScheduler .getMissingParentStages() 
=> dagScheduler.subMissingTasks(readyStage) 


// add tasks to the taskScheduler 
=> taskScheduler.submitTasks(new TaskSet(tasks)) 
=> fifoSchedulableBuilder.addTaskSetManager (taskSet) 


// send tasks 
=> sparkDeploySchedulerBackend.reviveoffers() 
=> driverActor ! ReviveOffers 
=> sparkDeploySchedulerBackend.makeOoffers() 
=> sparkDeploySschedulerBackend.1launchTasks() 
=> foreach task 
CoarseGrainedExecutorBackend(executorId) ! LaunchTask(serializedTastk) 


代码 的 文字 描述 
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Worker Node 1 


ExecutorRunner 


Executor 
task.run( 


3 ShuffleMap Tasks 1 ResultTask 
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当 用 户 的 program 调用 val sc = new Sparkcontext(sparkconf) 时 ， 这 个 语句 会 帮助 program 启动 诸多 有 关 driver 通信 、job 
执行 的 对 象 、 线 程 、actor 等 ， 该 语句 确立 了 program 的 driver 地 位 。 


生成 Job 逻辑 执行 图 


Driver program 中 的 transformation() 建立 computing chain (一 系列 的 RDD) ， 每 个 RDD 的 compute() 定义 数据 来 了 怎么 
计算 得 到 该 RDD 中 partition 的 结果 ，getDependencies() 定义 RDD 之 间 partition 的 数据 依赖 。 


生成 Job 物理 执行 图 


每 个 action() 触发 生成 一 个 job， 在 dagScheduler.runJob0 的 时 候 进行 stage 划分 ， 在 submitStage() 的 时 候 生 成 该 stage 
包含 的 具体 的 ShuffleMapTasks 或 者 ResultTasks， 然 后 将 tasks 打包 成 TaskSet 交 给 taskScheduler， 如 果 taskSet 可 以 运 
行 就 将 tasks 交 给 sparkDeploySchedulerBackend 去 分 配 执行 。 


分 配 Task 


sparkDeploySchedulerBackend 接收 到 taskSet 后 ， 会 通过 自 带 的 DriverActor 将 serialized tasks 发 送 到 调度 器 指定 的 
worker node 上 的 CoarseGrainedExecutorBackend Actor 上 。 


Job 接收 


Worker 端 接收 到 tasks 后 ， 执 行 如 下 操作 


coarseGrainedExecutorBackend ! LaunchTask(serializedTask) 
=> executor.launchTask() 
=> executor.threadPool.execute(new TaskRunner(taskId, serializedTask)) 


executor 将 task 包装 成 taskRunner， 并 从 线程 池 中 抽取 出 一 个 空闲 线程 运行 task。 一 个 
CoarseGrainedExecutorBackend 进程 有 且 仅 有 一 个 executor 对 象 。 


Task 运行 


下 图 展示 了 task 被 分 配 到 worker node 上 后 的 执行 流程 及 driver 如 何 义理 task 的 result。 
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Master Node Worker Node 1 


ExecutorRunner 



























Driver 


def main() { blockManager 


val sc = new SparkContext() 

val rdd = sc.makeRDD() 

val finalRDD = rdd.transformation() 
val result = finalRDD.action() 


} 


LinkedHashMap 
[Blockld, Entry] 





Size(result) > akkaFrameSize 
blockManager.putBytes(resu 岂 


dagScheduler 


taskScheduler 


sparkDeploySchedulerBackend 





driver ! Status 





ThreadPool 





return result 
directResult / 
indirectResult 


blockManager 
getRemoteBytes 
(indirectRgesult.blockld) 


eyisterMapOutputs(Array[MapStatus]) 


mapOutputTrackerMaster 
ShuffleWriterGroup 
Array[BlockObjectW /riter] 


【) Cl 


snuTileVVriters 


Result of ShuffleMap Task 
MapStatus 
MapStatus(block Managerld, Size[FSi=0, FSi-1, FSi-3]) 


Result of ResultTask 
func(context, rdd.iterator(split, context)) 


Executor 收 到 serialized 的 task 后 ， 先 deserialize 出 正常 的 task， 然 后 运行 task 得 到 其 执行 结果 directResult， 这 个 结果 
要 送 回 到 driver 那里 。 但 是 通过 Actor 发 送 的 数据 包 不 易 过 大 ， 如 果 result 比较 大 (比如 groupByKey 的 result) 先 把 
result 存放 到 本 地 的 “内 存 十 磁盘 "上 ， 由 blockManager 来 管理 ， 只 把 存储 位 置信 息 (indirectResult) 发 送 给 driver， 
driver 需要 实际 的 result 的 时 候 ， 会 通过 HTTP 去 fetch。 如 果 result 不 大 (小 于 spark.akka.framesize = 10MB ) ， 那 么 直接 
发 送 给 driver。 


上 面 的 描述 还 有 一 些 细节 : 如 果 task 运行 结束 生成 的 directResult > akka.frameSize，directResult 会 被 存放 到 由 
blockManager 管理 的 本 地 “内 存 十 磁盘 ”上 。BlockManager 中 的 memoryStore 开辟 了 一 个 LinkedHashMap 来 存储 要 存放 
到 本 地 内 存 的 数据 。LinkedHashMap 存储 的 数据 总 大 小 不 超过 Runtime.getRuntime.maxMemory * 
spark.storage.memoryFraction(default 0.6) 。 如 果 LinkedHashMap 剩余 空间 不 足以 存放 新 来 的 数据 ， 就 将 数据 交 给 
diskStore 存放 到 人 磁 龟 上 ， 但 前 提 是 该 数据 的 storageLevel 中 包含“ 磁盘 "。 


In TaskRunner.run() 
// deserialize task, run it and then send the result to 
=> coarseGrainedExecutorBackend.statusUpdate() 
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=> task = ser.deserialize(serializedTask) 
=> Value = task.run(taskId) 
=> directResult = new DirectTaskResult(ser.serialize(value)) 
=> if( directResult.size() > akkaFrameSize() ) 
indirectResult = blockManager .putBytes(taskId, directResult, MEMORY+DISK+SER) 
else 
return directResult 
=> coarseGrainedExecutorBackend,.statusUpdate(result) 
=> driver ! StatusUpdate(executorId, taskId, result) 


ShuffleMapTask 和 ResultTask 生成 的 result 不 一 样 。ShuffleMapTask 生成 的 是 MapStatus，MapStatus 包含 两 项 内 容 : 
一 是 该 task 所 在 的 BlockManager 的 BlockManagerld (实际 是 executorld + host, port, nettyPort) ， 二 是 task 输出 的 每 个 
FileSegment 大 小 。ResultTask 生成 的 result 的 是 func 在 partition 上 的 执行 结果 。 上 比如 count( 的 func 就 是 统计 
partition 中 records 的 个 数 。 由 于 ShuffleMapTask 需要 将 FileSegment 写 入 磁盘 ， 因 此 需要 输出 流 Writers， 这 些 writers 是 
由 blockManger 里 面 的 shuffleBlockManager 产生 和 控制 的 。 


In task.run(taskId) 

// if the task is ShuffleMapTask 

=> shuffleMapTask.runTask(context) 

=> shufflewriterGroup = shuffleBlockManager.forMapTask(shuffleId, partitionId, numOutputSplits) 
=> shufflewriterGroup.writers(bucketId).write(rdd.iterator(split, context)) 

=> return MapStatus(blockManager.blockManagerId, Array[compressedSize(fileSegment)]) 


//If the task is ResultTask 
=> return func(context, rdd.iterator(split, context)) 


Driver 收 到 task 的 执行 结果 result 后 会 进行 一 系列 的 操作 : 首先 告诉 taskScheduler 这 个 task 已 经 执行 完 ， 然 后 去 分 析 
result。 由 于 result 可 能 是 indirectResult， 需 要 先 调 用 blockManager.getRemoteBytes() 去 fech 实际 的 result， 这 个 过 程 下 
节 会 详解 。 得 到 实际 的 result 后 ， 需 要 分 情况 分 析 ， 如 果 是 ResultTask 的 result， 那 么 可 以 使 用 ResultHandler 对 result 
进行 driver 端的 计算 (比如 count() 会 对 所 有 ResultTask 的 result 作 sum) ， 如 果 result 是 ShuffleMapTask 的 
MapStatus， 那 么 需要 将 MapStatus (ShuffleMapTask 输出 的 FileSegment 的 位 置 和 大 小 信息 ) 存放 到 
mapOutputTrackerMaster 中 的 mapStatuses 数据 结构 中 以 便 以 后 reducer shuffle 的 时 候 查 询 。 如 果 driver 收 到 的 task 
是 该 stage 中 的 最 后 一 个 task， 那 么 可 以 submit 下 一 个 stage， 如 果 该 stage 已 经 是 最 后 一 个 stage， 那 么 告诉 
dagScheduler job 已 经 完成 。 


After driver receives StatusUpdate(result) 
=> taskScheduler.statusUpdate(taskId, state, result.value) 
=> taskResultGetter.enqueueSuccessfulTask(taskSet, tid, result) 
=> if result is IndirectResult 
serializedTaskResult = blockManager .getRemoteBytes(IndirectResult.blockId) 
=> scheduler.handleSuccessfulTask(taskSetManager, tid, result) 
=> taskSetManager .handleSuccessfulTask(tid, taskResult) 
=> dagSsScheduler.taskEnded(result.value, result.accumUpdates) 
=> dagSschedulerEventProcessActor ! CompletionEvent(result, accumUpdates) 
=> dagScheduler.handleTaskCompletion(completion) 
=> Accumulators.add(event.accumUpdates) 


// If the finished task is ResultTask 

=> if (job.numFinished == job.numPartitions) 
lJistenerBus.post(SparkListenerJobEend(job.jobId, JobSucceeded)) 

=> JjJob.listener.taskSucceeded(outputId, result) 

=> jobwaiter.taskSucceeded(index, result) 

=> resultHandler (index, result) 


// if the finished task is ShuffleMapTask 

=> stage.addOutputLoc(smt.partitionId, status) 

=> if (all tasks in current stage have finished) 
mapOutputTrackerMaster.registerMapOutputs(shuffleId, Array[MapStatus]|) 
mapStatuses.put(shuffleId, Array[MapStatus]() ++ statuses) 

=> submitStage(stage) 


Shuffle read 
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上 一 节 描 述 了 task 运行 过 程 及 result 的 处 理 过 程 ， 这 一 节 描 述 reducer (需要 shuffle 的 task ) 是 如 何 获 取 到 输入 数据 的 。 
天 于 reducer 如 何 处 理 输入 数据 已 经 在 上 一 章 的 shuffle read 中 解释 了 。 


问题 : reducer 怎么 知道 要 去 哪里 fetch 数据 ? 


Worker Node 1] 


ExecutorRunner 


Master Node 


Driver 


Executor 


BasicBlockFetcherlterator 


pckManager.getMultiple(blockByAddress,) 


def main() { 
val sc = new SparkContext() 
val rdd = sc.makeRDD() 
val finalRDD = rdd.transformation() 
val result = finalRDD.action() 


} 


mapOutputTrackerWorker 


mapOutputTrackerMaster 


getServerStatuses() 


blockStoreShuffleFetcher 
GetMapOutputStatuses(shuffleld) SASS = DIODKSPYAUOIGSs 


fetch(shuffleld, reduceld) 


mapStatuses: 
HashMap<stageld, 
Array[MapStatus]> 


statuses: Array[(BlockManagerld, FS)] 
for given reducer 


rdd.iteraton) 





reducer 首先 要 知道 parent stage 中 ShuffleMapTask 输出 的 FileSegments 在 哪个 节点 。 这 个 信 0 ShuffleMapTask 完成 
时 已 经 送 到 了 driver 的 mapOutputTrackerMaster， 并 存放 到 了 ei HashMap 里 面 ， 给 定 stageld， 可 以 获取 
该 stage 中 ShuffleMapTasks 生成 的 FileSegments 信息 Array[MapStatus]， 通 过 Array(taskld) i task 输出 的 
FileSegments 位 置 (blockManagerld) 及 每 个 FileSegment 大 小 。 


当 reducer 需要 fetch 输入 数据 的 时 候 ， 会 首先 调用 blockStoreShuffleFetcher 去 获取 输入 数据 (FileSegments) 的 位 置 。 
blockStoreShuffleFetcher 通过 调用 本 地 的 MapOutputTrackerWorker 去 完成 这 个 任务 ，MapOutputTrackerWorker 使 用 
mapOutputTrackerMasterActorRef 来 与 Wane ne 通信 获取 MapStatus 信息 。 
blockStoreShuffleFetcher 对 获取 到 的 MapStatus 信息 进行 加 工 ， 提 取出 该 reducer 应 该 去 哪些 节点 上 获取 哪些 
FileSegment 的 信息 ， 这 个 信息 存放 在 blocksByAddress 里 面 。 之 后 ，blockStoreShuffleFetcher 将 获取 FileSegment 数据 


的 任务 交 给 basicBlockFetcherlterator。 


rdd.iterator() 

=> rdd(e.g., ShuffledRDD/CoGroupedRDD).compute() 

=> SparkEnv.get.shuffleFetcher.fetch(shuffledId, split.index, context, ser) 
=> blockStoreShuffleFetcher.fetch(shuffleId, reduceId, context, serializer) 
=> statuses = MapOutputTrackerworker .getServerStatuses(shuffleId, reduceId) 


=> blocksByAddress: Seq[(BlockManagerId, Seq[(BlockId, Long)]1)] = compute(statuses) 


=> basicBlockFetcherIterator = blockManager .getMultiple(blocksByAddress, serializer) 
=> itr = basicBlockFetcherIiterator.flatMap(unpackBlock) 
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basicBlockFetcherlterator 收 到 获取 数据 的 任务 后 ， 会 生成 一 个 个 fetchRequest， 每 个 fetchRequest 包含 去 某 个 节点 获取 
若干 个 FileSegments 的 任务 。 图 中 展示 了 reducer-2 需要 从 三 个 worker node 上 获取 所 需 的 白色 FileSegment (FS)。 总 的 
数据 获取 任务 由 blocksByAddress 表示 ， 要 从 第 一 个 node 获取 4 个 ， 从 第 二 个 node 获取 3 个 ， 从 第 三 个 node 获取 4 


Le 


为 了 加 快 任务 获取 过 程 ， 显 然 要 将 总 任务 划分 为 子 任 务 (fetchRequest) ， 为 每 个 任务 分 配 一 个 线程 去 fetch。Spark 为 


统 柑 块 如 何 协 调 完 成 整个 Job 57 


Apache Spark 的 设计 与 实现 


每 个 reducer 启动 5 个 并 行 fetch 的 线程 (Hadoop 也 是 默认 启动 5 个 ) 。 由 于 fetch 来 的 数据 会 先 被 放 到 内 存 作 缓冲 ， 因 此 
一 次 fetch 的 数据 不 能 太 多 ，Spark 设 定 不 能 超过 spark.reducer .maxMbInFlight=48MB 。 注意 这 48MB 的 空间 是 由 这 5 个 
fetch 线程 共享 的 ， 因 此 在 划分 子 任务 时 ， 尽 量 使 得 fetchRequest 不 超过 48MB / 5 = 9.6MB 。 如 图 在 node 1 中 ，Size(FS0O- 
2) + Size(FS1-2) < 9.6MB 但 是 Size(FS0-2) + Size(FS1-2) + Size(FS2-2) > 9.6MB， 因 此 要 在 tL-r2 和 t2-r2 处 断 开 ， 所 以 图 
中 有 两 个 fetchRequest 都 是 要 去 node 1 fetch。 那 么 会 不 会 有 fetchRequest 超过 9.6MB ? 当然 会 有 ， 如 果 某 个 
FileSegment 特别 大 ， 仍 然 需 要 一 次 性 将 这 个 FileSegment fetch 过 来 。 另外， 如 果 reducer 需要 的 某 些 FileSegment 就 在 
本 节点 上 ， 那 么 直接 进行 local read。 最 后 ， 将 fetch 来 的 FileSegment 进行 deserialize， 将 里 面 的 records 以 iterator 的 形 
式 提 供给 rdd.compute()， 整 个 shuffle read 结束 。 


In basicBlockFetcherIterator: 


// generate the fetch requests 

=> basicBlockFetcherIterator.initialize() 

=> remoteRequests = splitLocalRemoteBlocks() 

=> fetchRequests ++= Utils.randomize(remoteRequests) 


// fetch remote blocks 
=> sendRequest(fetchRequests.dequeue()) until Size(fetchRequests) > maxBytesInFlight 
=> blockManager .connectionManager .sendMessageReliably(cmId, 
blockMessageArray .toBufferMessage) 
=> fetchResults.put(new FetchResult(blockId, sizeMap(blockId))) 
=> dataDeserialize(blockId, blockMessage.getData, serializer) 


// fetch local blocks 
=> getLocalBlocks() 
=> fetchResults.put(new FetchResult(id, 0, () => iter)) 


下 面 再 讨论 一 些 细节 问题 : 


reducer 如 何 将 fetchRequest 信息 发 送 到 目标 节点 ? 目标 节点 如 何 义理 fetchRequest 信息 ， 如 何 读 取 FileSegment 并 回 
送 给 reducer ? 
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rdd.iterator() 伙 到 ShuffleDependency 时 会 调用 BasicBlockFetcherlterator 去 获取 FileSegments。 
BasicBlockFetcherlterator 使 用 blockManager 中 的 connectionManager 将 fetchRequest 发 送 给 其 他 节点 的 
connectionManager。connectionManager 之 间 使 用 NIO 模式 通信 。 其 他 节点 ， 上 比如 worker node 2 上 的 


connectionManager 收 到 消息 后 ， 会 交 给 blockManagerWorker 义理 ，blockManagerWorker 使 用 blockManager 中 的 









diskStore 去 本 地 磁盘 上 读 取 fetchRequest 要 求 的 FileSegments， 然 后 仍然 通过 connectionManager 将 FileSegments 发 送 


回去 。 如 果 使 用 了 FileConsolidation，diskStore 还 需要 shuffleBlockManager 来 提供 blockld 所 在 的 具体 位 置 。 如 果 


FileSegment 不 超过 spark.storage.memoryMapThreshold=8KB ， 那 么 diskStore 在 读 取 FileSegment 的 时 候 会 直接 将 


FileSegment 放 到 内 存 中 ， 否 则 ， 会 使 用 RandomAccessFile 中 FileChannel 的 内 存 映 射 方法 来 读 取 FileSegment (这 样 可 


以 将 大 的 FileSegment 加 载 到 内 存 ) 。 


当 BasicBlockFetcherlterator 收 到 其 他 节点 返回 的 serialized FileSegments 后 会 将 其 放 到 fetchResults: Queue 里 面 ， 并 进 


行 deserialization， 所 以 fetchResults: Queue 就 相当 于 在 Shuffle details 那 一 章 提 到 的 softBuffer。 如 果 
BasicBlockFetcherlterator 所 需 的 某 些 FileSegments 就 在 本 地 ， 会 通过 diskStore 直接 从 本 地 文件 读 取 ， 并 放 到 
fetchResults 里 面 。 最 后 reducer 一 边 从 FileSegment 中 边 读 取 records 一 边 处 理 。 
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After the blockManager receives the fetch request 


=> connectionManager .receiveMessage(bufferMessage) 
=> handleMessage(connectionManagerId, message, connection) 


// invoke blockManagerWworker to read the block (FileSegment) 
=> blockManagerworker .onBlockMessageReceive() 
=> blockManagerworker .processBlockMessage(blockMessage) 
=> buffer = blockManager .getLocalBytes(blockId) 
=> buffer = diskStore.getBytes(blockId) 
=> fileSegment = diskManager.getBlockLocation(blockId) 
=> shuffleManager .getBlockLocation() 
=> if(fileSegment < minMemoryMapBytes ) 

buffer = ByteBuffer .allocate(fileSegment ) 

else 
channel.map(MapMode ,READ_ONLY， segment.offset, segment.1length) 


每 个 reducer 都 持 有 一 个 BasicBlockFetcherlterator， 一 个 BasicBlockFetcherlterator 理论 上 可 以 持 有 48MB 的 
fetchResults。 每 当 fetchResults 中 有 一 个 FileSegment 被 读 取 完 ， 融 会 一 下 子 去 fetch 很 多 个 FileSegment， 下 到 48MB 被 
填 满 。 


BasicBlockFetcherIiterator.next() 

=> result = results.task() 

=> while (!'fetchRequests.isEmpty && 
(bytesInFlight == 0 || bytesInFlight + fetchRequests.front.size <= maxBytesInFlight)) { 
sendRequest(fetchRequests.dequeue( )) 


} 


=> result.deserialize() 


Discussion 


这 一 章 写 了 三 天 ， 也 是 我 这 个 月 来 心情 最 不 好 的 几 天 。Anyway， 继 续 总 结 。 


架构 部 分 其 实 没有 什么 好 说 的 ， 就 是 设计 时 尽量 功能 独立 ， 模 块 独立 ， 松 看 合 。BlockManager 设计 的 不 错 ， 就 是 管 的 东西 
太 多 (数据 块 、 内 存 、 和 磁盘 、 通 信 ) 。 


这 一 章 主要 探讨 了 系统 中 各 个 模块 是 怎么 协同 来 完成 job 的 生成 、 提 交 、 和 运行、 结果 收集 、 结 果 计 算 以 及 shuffle 的 。 贴 了 很 
多 代码 ， 也 了 画 了 很 多 图 ， 虽 然 细 节 很 多 ， 但 远 没 有 达到 源码 的 细致 程度 。 如 果 有 地 方 不 明白 的 ， 请 根据 拉 述 阅读 一 下 源码 
吧 。 


如 果 想 进一步 了 解 blockManager， 可 以 参阅 Jerry Shao 写 的 Spark 源 码 分 析 之 -Storage 模 块 。 
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Cache 和 Checkpoint 


作为 区 别 于 Hadoop 的 一 个 重要 feature，cache 机 制 保证 了 需要 访问 重复 数据 的 应 用 《如 迭代 型 算法 和 交互 式 应 用 ) 可 以 运 
行 的 更 快 。 与 Hadoop MapReduce job 不 同 的 是 Spark 的 逻辑 /物理 执行 图 可 能 很 庆 大 ，task 中 computing chain 可 能 会 很 
长 ， 计 算 某 些 RDD 也 可 能 会 很 耗 时 。 这 时 ， 如 果 task 中 途 运 行 出 错 ， 那 么 task 的 整个 computing chain 需要 重 算 ， 代 价 太 
高 。 因 此 ， 有 必要 将 计算 代价 较 大 的 RDD checkpoint 一 下 ， 这 样 ， 当 下 游 RDD 计算 出 错时 ， 可 以 直接 从 checkpoint 过 的 


RDD 那里 读 取 数据 继续 算 。 


Cache 机 制 


回 到 Overview 提 到 的 GroupByTest 的 例子 ， 里 面 对 FlatMappedRDD 进行 了 cache， 这 样 Job 1 在 执行 时 就 站 接 从 


FlatMappedRDD 开始 算 了 。 可 见 cache 能 够 让 重复 数据 在 同一 个 application 中 的 jobs 间 共 享 。 


逻辑 执行 图 : 
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问题 : 哪些 RDD 需要 cache ? 
会 被 重复 使 用 的 (但 不 能 太 大 ) 。 
问题 : 用 户 怎 么 设 定 哪些 RDD 要 cache? 


因为 用 户 只 与 driver program 打交道 ， 因 此 只 能 用 rdd.cache() 去 cache 用 户 能 看 到 的 RDD。 所 谓 能 看 到 指 的 是 调用 
transformation() 后 生成 的 RDD， 而 某 些 在 transformation() 中 Spark 自己 生成 的 RDD 是 不 能 被 用 户 直 接 cache 的 ， 上 比如 
reduceByKey() 中 会 生成 的 ShuffledRDD、MapPartitionsRDD 是 不 能 被 用 户 直 接 cache 的 。 


问题 : driver program 设 定 rdd.cache() 后 ， 系 统 怎么 对 RDD 进行 cache ? 


先 不 看 实现 ， 自 己 来 想象 一 下 如 何 完 成 cache : 当 task 计算 得 到 RDD 的 某 个 partition 的 第 一 个 record 后 ， 就 去 判断 该 
RDD 是 否 要 被 cache， 如 果 要 被 cache 的 话 ， 将 这 个 record 及 后 续 计 算 的 到 的 records 直接 丢 给 本 地 blockManager 的 
memoryStore， 如 果 memoryStore 存 不 下 就 交 给 diskStore 存放 到 磁 禹 。 


实际 实现 与 设想 的 基本 类 似 ， 区 别 在 于 : 将 要 计算 RDD partition 的 时 候 (而 不 是 已 经 计算 得 到 第 一 个 record 的 时 候 ) 就 去 
判断 partition 要 不 要 被 cache。 如 果 要 被 cache 的 话 ， 先 将 partition 计算 出 来 ， 然 后 cache 到 内 存 。cache 只 使 用 
memory， 写 位 和 意 的话 那 束 叫 checkpoint 了 。 


调用 rdd.cache() 后 ， rdd 就 变 成 persistRDD 了 ， 其 StorageLevel 为 MEMORY _ONLY。persistRDD 会 告知 driver 说 自己 
是 需要 被 persist 的 。 
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如 果 用 代码 表示 : 


rdd.iterator() 
=> SparkEnv.get.cacheManager.getOorCompute(thisRDD, split, context, storageLevel) 
=> key = RDDB1lockId(rdd.id, split.index) 
=> blockManager .get (key) 
=> computedValues = rdd.computeOrReadCheckpoint(split, context) 
if (isCheckpointed) firstParent[T].iterator(split, context) 
else compute(split, context) 
=> elements = new ArrayBuffer[Anyl] 
=> elements ++= computedValues 
=> updatedBlocks = blockManager .put(key, elements, tellMaster = true) 


当 rdd.iterator() 被 调用 的 时 候 ， 也 就 是 要 计算 该 rdd 中 某 个 partition 的 时 候 ， 会 先 去 cacheManager 那里 领取 一 个 
blockld， 表 明 是 要 存 哪个 RDD 的 哪个 partition， 这 个 blockld 类 型 是 RDDBlockld (memoryStore 里 面 可 能 还 存放 有 task 
的 result 等 数据 ， 因 此 blockld 的 类 型 是 用 来 区 分 不 同 的 数据 ) 。 然 后 去 blockManager 里 面 查看 该 partition 是 不 是 已 经 被 
checkpoint 了 ， 如 果 是 ， 表 明 以 前 运行 过 该 task， 那 束 不 用 计算 该 partition 了 ， 让 接 从 checkpoint 中 读 取 该 partition 的 所 
有 records 放 到 叫做 elements 的 ArrayBuffer 里 面 。 如 果 没 有 被 checkpoint 过 ， 先 将 partition 计算 出 来 ， 然 后 将 其 所 有 
records 放 到 elements 里 面 。 最 后 将 elements 交 给 blockManager 进行 cache。 
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blockManager 将 elements (也 就 是 partition) 存放 到 memoryStore 管理 的 LinkedHashMap[Blockld, Entry] 里 面 。 如 果 
partition 大 于 memoryStore 的 存储 极限 (默认 是 60% 的 heap) ， 和 那么 直接 返回 说 存 不 下 。 如 果 剩 余 空 间 也 许 能 放下 ， 会 先 
drop 掉 一 些 早先 被 cached 的 RDD 的 partition， 为 新 来 的 partition 膳 地方， 如 果 腾 出 的 地 方 够 ， 就 把 新 来 的 partition 放 到 
LinkedHashMap 里 面 ， 腾 不 出 就 返回 说 存 不 下 。 注 意 drop 的 时 候 不 会 去 drop 与 新 来 的 partition 同属 于 一 个 RDD 的 
partition。 drop 的 时 候 先 drop 最 早 被 cache 的 partition。 (说 好 的 LRU 蔡 换 算法 呢 ? ) 


问题 : cached RDD 怎么 被 读 取 ? 


下 次 计算 (一 般 是 同一 application 的 下 一 个 job 计算 ) 时 如 果 用 到 cached RDD，task 会 直接 去 blockManager 的 
memoryStore 中 读 取 。 上 有 具体 地 讲 ， 当 要 计算 某 个 rdd 中 的 partition 时 候 (通过 调用 rdd.iterator()) 会 先 去 blockManager 里 
面 查找 是 否 已 经 被 cache 了， 如果 partition 被 cache 在 本 地 ， 就 直接 使 用 blockManager.getLocal() 去 本 地 memoryStore 
里 读 取 。 如 果 该 partition 被 其 他 节点 上 blockManager cache 了 ， 会 通过 blockManager.getRemote() 去 其 他 节点 上 读 取 ， 读 
取 过 程 如 下 图 。 
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获取 cached partitions 的 存储 位 置 : partition 被 cache 后 所 在 节点 上 的 blockManager 会 通知 driver 上 的 
blockMangerMasterActor 说 某 rdd 的 partition 已 经 被 我 cache 了 ， 这 个 信息 会 存储 在 blockMangerMasterActor 的 
blockLocations: HashMap 中 。 等 到 task 执行 需要 cached rdd 的 时 候 ， 会 调用 blockManagerMaster 的 
getLocations(blockld) 去 询问 某 partition 的 存储 位 置 ， 这 个 询问 信息 会 发 到 driver 那里 ，driver 查询 blockLocations 获得 位 
置信 息 并 将 信息 送 回 。 
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读 取 其 他 节点 上 的 cached partition : task 得 到 cached partition 的 位 置信 息 后 ， 将 GetBlock(blockld) 的 请 求 通 
connectionManager 发 送 到 目标 节点 。 目 标 节点 收 到 请 求 后 从 本 地 ee 那里 的 memoryStore 读 取 ee 
partition， 最 后 发 送 回 来 。 


Checkpoint 


问题 : 哪些 RDD 需要 checkpoint ? 


运算 时 间 很 长 或 运算 量 太 大 才能 得 到 的 RDD，computing chain i RDD 很 多 的 RDD。 实际 上 ， 将 
ShuffleMapTask 的 输出 结果 存放 到 本 地 磁盘 也 算是 checkpoint， 只 不 过 这 个 checkpoint 的 主要 目的 是 去 partition 输出 数 
据 。 


问题 : 什么 时 候 checkpoint ? 


cache 机 制 是 每 计算 出 一 个 要 cache 的 partition 就 直接 将 其 cache 到 内 存 了 。 但 checkpoint 没有 使 用 这 种 第 一 次 计算 得 到 
就 存储 的 方法 ， 而 是 等 到 job 结束 后 另外 和 启动 专门 的 job 去 完成 checkpoint 。 也 就 是 说 需要 checkpoint 的 RDD 会 被 计算 
两 次 。 因 此 ， 在 使 用 rdd.checkpoint() 的 时 候 ， 建 议 加 上 rdd.cache()， 这 样 第 二 次 运行 的 job 就 不 用 再 去 计算 该 rdd 了 ， 
直接 读 取 cache 写 磁 盘 。 其 实 Spark 提供 了 rdd.persist(StorageLevel.DISK_ONLY) 这 样 的 方法 ， 相 当 于 cache 到 磁盘 上 ， 

这 样 可 以 做 到 rdd 第 一 次 被 计算 得 到 时 就 存储 到 磁盘 上 ， 但 这 个 persist 和 checkpoint 有 很 多 不 同 ， 之 后 会 讨论 。 


问题 : checkpoint 怎么 实现 ? 


RDD 需 过 [Initialized --> marked for checkpointing --> checkpointing in progress --> checkpointed ] 这 几 个 阶段 才能 被 
Sh 


Initialized : 首先 driver program 需要 使 用 rdd.checkpoint() 去 设 定 哪些 rdd 需要 checkpoint， 设 定 后 ， 该 rdd 就 接受 
RDDCheckpointData 管理 。 用 户 还 要 设 定 checkpoint 的 存储 路 径 ， 一 般 在 HDFS 上 。 


marked for checkpointing : 初始 化 后 ，RDDCheckpointData 会 将 rdd 标记 为 MarkedForCheckpoint。 


checkpointing in progress : 每 个 job 运行 结束 后 会 调用 finalRdd.doCheckpoint()，finalRdd 会 顺 着 computing chain 回溯 
打 描 ， 碰 到 要 checkpoint 的 RDD 就 将 其 标记 为 CheckpointinglnProgress， 然 后 将 写 磁 盘 (比如 写 HDFS) 需要 的 配置 文件 
(如 core-site.xml 等 ) broadcast 到 其 他 worker 节点 上 的 blockManager。 完 成 以 后 ， 启 动 一 个 job 来 完成 checkpoint (使 


用 rdd.context.runJob(rdd, CheckpointRDD.writeToFile(path.toSstring, broadcastedConf)) ) o 


checkpointed : job 完成 checkpoint 后 ， 将 该 rdd 的 dependency 全 部 清 掉 ， 并 设 定 该 rdd 状态 为 checkpointed。 然 后 ， 为 
该 rdd 强加 一 个 依赖 ， 设 置 该 rdd 的 ee rdd 为 CheckpointRDD， 该 CheckpointRDD 负责 以 后 读 取 在 文件 系统 上 的 
checkpoint 文件 ， 生 成 该 rdd 的 partition。 


有 意思 的 是 我 在 driver program 里 checkpoint 了 两 个 rdd， 结 果 只 有 一 个 (下 面 的 result) 被 checkpoint 成 功 ，pairs2 没有 
被 checkpoint， 也 不 知道 是 bug 还 是 故意 只 checkpoint 下 游 的 RDD : 


Wall 凤 alaead 呈 三 Aimeay En ena a a 20 CS 下 
(RS (2 0 (Th) 
val pairs1 = sc.parallelize(datai, 3) 


valmadata2 = Area en Chen dl A (2 BB (6 (4 D0 
val pairs2 = sc.parallelize(data2, 2) 


pairs2.checkpoint 


val result = pairs1. join(pairs2) 
result.checkpoint 


问题 : 怎么 读 取 checkpoint 过 的 RDD ? 
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在 runJob() 的 时 候 会 先 调 用 finalRDD 的 partitions() 来 确定 最 后 会 有 多 个 task。rdd.partitions() 会 去 检查 (通过 
RDDCheckpointData 去 检查 ， 因 为 它 负责 管理 被 checkpoint 过 的 rdd) 该 rdd 是 会 否 被 checkpoint 过 了 ， 如 果 该 rdd 已 经 
被 checkpoint 过 了 ， 直 接 返 回 该 rdd 的 partitions 也 就 是 Array[Partition]。 


当 调 用 rdd.iterator() 去 计算 该 rdd 的 partition 的 时 候 ， 会 调用 computeOrReadCheckpoint(split: Partition) 去 查看 该 rdd 是 
否 被 checkpoint 过 了 ， 如 果 是 ， 就 调用 该 rdd 的 parent rdd 的 iterator( 也 就 是 CheckpointRDD .iterator()，CheckpointRDD 
负责 读 取 文 件 系统 上 的 文件 ， 生 成 该 rdd 的 partition。 这 就 解释 了 为 什么 那么 trickly 地 为 checkpointed rdd 添加 一 个 
parent CheckpointRDD。 


问题 : cache 与 checkpoint 的 区 别 ? 


关于 这 个 问题 ，Tathagata Das 有 一 段 回 答 : There is a significant difference between cache and checkpoint. Cache 
materializes the RDD and keeps it in memory and/or disk (其 实 只 有 memory) . But the lineage (也 就 是 computing 
chain) of RDD (that is, seq of operations that generated the RDD) will be remembered, so that if there are node failures 
and parts of the cached RDDs are lost, they can be regenerated. However, checkpoint saves the RDD to an HDFS file 
and actually forgets the lineage completely. This is allows long lineages to be truncated and the data to be saved 
reliably In HDFS (which Is naturally fault tolerant by replication). 


深入 一 点 讨论 ，rdd.persist(StorageLevel.DISK_ONLY) 与 checkpoint 也 有 区 别 。 前 者 虽然 可 以 将 RDD 的 partition 持久 化 到 
磁盘 ， 但 该 partition 由 blockManager 管理 。 一 旦 driver program 执行 结束 ， 也 就 是 executor 所 在 进程 
CoarseGrainedExecutorBackend stop，blockManager 也 会 stop， 被 cache 到 磁盘 上 的 RDD 也 会 被 清空 (整个 
blockManager 使 用 的 local 文件 夹 被 删除 ) 。 而 checkpoint 将 RDD 持久 化 到 HDFS 或 本 地 文件 夹 ， 如 果 不 被 手动 remove 
掉 (话说 怎么 remove checkpoint 过 的 RDD?) ， 是 一 直 存 在 的 ， 也 就 是 说 可 以 被 下 一 个 driver program 使 用 ， 而 
cached RDD 不 能 被 其 他 dirver program 使 用 。 


Discussion 


Hadoop MapReduce 在 执行 job 的 时 候 ， 不 停 地 做 持久 化 ， 每 个 task 运行 结束 做 一 次 ， 每 个 job 运行 结束 做 一 次 ( 写 到 
HDFS) 。 在 task 运行 过 程 中 也 不 停 地 在 内 存 和 磁 瘟 间 swap swap 去 。 可 是 训 刺 的 是 ， Hadoop task 太 傻 ， 中 途 出 
错 需 要 完全 重新 运行 ， 比 如 shuffle 了 一 半 的 数据 存放 到 了 磁盘 ， 下 次 重新 运行 时 仍然 要 重新 shuffle。 Spark 好 的 一 点 在 于 尽 
量 不 去 持久 化 ， 所 以 使 用 pipeline，cache 等 机 制 。 用 户 如 果 感 沉 job 可 能 会 出 错 可 以 手动 去 checkpoint 一 些 critical 的 
RDD，job 如 果 出 错 ， 下 次 运行 时 直接 从 checkpoint 中 读 取 数据 。 唯 一 不 足 的 是 ，checkpoint 需要 两 次 运行 jo 


Example 


貌似 还 没有 发 现 官 方 给 出 的 checkpoint 的 例子 ， 这 里 我 写 了 一 


package internals 


import org.apache.spark.SparkContext 
import org.apache.spark.SparkContext._ 
import org.apache.spark.SparkConf 


object groupByKeyTest { 


def main(args: Array[String]) { 

val conf = new SparkConf().setAppName("GroupByKey").setMaster("local") 
val sc = new SparkContext(conf) 
sc.setCheckpointDir("/Users/xulijie/Documents/data/checkpoint") 


val data = Array[(Int, Char)]((1, 'a'), (2, 'b'), 
(3, 'c'), (4, 'd'), 
(5, 'e'), (3, ff) 
(2 0 (Ln) 
) 


val pairs = sc.parallelize(data, 3) 


pairs.checkpoint 
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pairs.count 
val result = pairs.groupByKey(2) 
result.foreachwith(i => i)((x, i) => println("[PartitionIndex " +i+"] "+ Xx)) 


printJln(result.toDebugString ) 
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Broadcast 


顾名思义 ，broadcast 融 是 将 数据 从 一 个 节点 发 送 到 其 他 各 个 节点 上 去 。 这 样 的 场景 很 多 ， 比 如 driver 上 有 一 张 表 ， 其 他 节 
点 上 运行 的 task 需要 lookup 这 张 表 ， 那 么 driver 可 以 先 把 这 张 表 copy 到 这 些 节点 ， 这 样 task 就 可 以 在 本 地 查 表 了 。 如 何 
实现 一 个 可 靠 高 效 的 broadcast 机 制 是 一 个 有 挑战 性 的 问题 。 先 看 看 Spark 官网 上 的 一 段 话 : 


Broadcast variables allow the programmer to keep a read-only variable cached on each machine rather than shipping a 
copy of It with tasks. They can be used, for example, to give every node a copy of a large input dataset in an efficient 
manner. Spark also attempts to distribute broadcast variables using efficient broadcast algorithms to reduce 
communication cost. 


问题 : 为 什么 只 能 broadcast 只 读 的 变量 ? 
这 就 涉及 一 致 性 的 问题 ， 如 果 变 量 可 以 被 更 新 ， 那 么 一 旦 变量 被 某 个 节点 更 新 ， 其 他 节点 要 不 要 一 块 更 新 ? 如 果 多 个 节点 同 


时 在 更 新 ， 更 新 顺序 是 什么 ? 怎么 做 同步 ? 还 会 涉及 fault-tolerance 的 问题 。 为 了 避免 维护 数据 一 致 性 问题 ，Spark 目前 只 
支持 broadcast 只 读 变 量 。 


问题 : broadcast 到 节点 而 不 是 broadcast 到 每 个 task ? 


因为 每 个 task 是 一 个 线程 ， 而 且 同 在 一 个 进程 运行 tasks 都 属于 同一 个 application。 因 此 每 个 节点 (executor) 上 放 一 份 就 
可 以 被 所 有 task 共享 。 


问题 : 具体 怎么 用 broadcast ? 


driver program 例子 : 


valecaean = se( Dt 2 03304 5 6 
val bdata = sc.broadcast(data) 


val rdd = sc.parallelize(1 to 6, 2) 
val observedSizes = rdd.map( => bdata.value.size) 


driver 使 用 sc.broadcast() 声明 要 broadcast 的 data，bdata 的 类 型 是 Broadcast。 


当 rdd.transformation(func) 需要 用 bdata 时 ， 直接 在 func 中 调用 ， 比如 上 面 的 例子 中 的 map() 就 使 用 了 
bdata.value.size。 


问题 : 怎么 实现 broadcast? 


broadcast 的 实现 机 制 很 有 意思 : 
1. 分 发 task 的 时 候 先 分 发 bdata 的 元 信息 


Driver 先 建 一 个 本 地 文件 夹 用 以 存放 需要 broadcast 的 data， 并 启动 一 个 可 以 访问 该 文件 夹 的 HttpServer。 当 调用 val bdata 
= sc.broadcast(data) 时 就 把 data 写 入 文件 夹 ， 同 时 写 入 driver 自己 的 blockManger 中 (StorageLeve| 为 内 存 十 磁盘 ) ， 获 
得 一 个 blockld， 类 型 为 BroadcastBlockld。 当 调用 rdd.transformation(func) 时 ， 如 果 func 用 到 了 bdata， 那 么 driver 
submitTask() 的 时 候 会 将 bdata 一 同 func 进行 序列 化 得 到 serialized task， 注 意 序列 化 的 时 候 不 会 序列 化 bdata 中 包含 的 
data。 上 一 章 讲 到 serialized task 从 driverActor 传递 到 executor 时 使 用 Akka 的 传 消息 机 制 ， 消 息 不 能 太 大 ， 而 实际 的 
data 可 能 很 大 ， 所 以 这 时 候 还 不 能 broadcast data。 


driver 为 什么 会 同时 将 data 放 到 磁盘 和 blockManager 里 面 ? 放 到 磁盘 是 为 了 让 HttpServer 访问 到 ， 放 到 
blockManager 是 为 了 让 driver program 自身 使 用 bdata 时 方便 (其 实 我 觉得 不 放 到 blockManger 里 面 也 行 ) 。 
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那么 什么 时 候 传送 真正 的 data ? 在 executor 反 序 列 化 task 的 时 候 ， 会 同时 反 序 列 化 task 中 的 bdata 对 象 ， 这 时 候 会 调用 
bdata 的 readObject( 方法 。 该 方法 先 去 本 地 blockManager 那里 询问 bdata 的 data 在 不 在 blockManager 里 面 ， 如 果 不 在 
就 使 用 下 面 的 两 种 fetch 方式 之 一 去 将 data fetch 过 来 。 得 到 data 后 ， 将 其 存放 到 blockManager 里 面 ， 这 样 后 面 运 行 的 
task 如 果 需 要 bdata 就 不 需要 再 去 fetch data 了 。 如 果 在 ， 就 直接 拿 来 用 了 。 


下 面 探 讨 broadcast data 时 候 的 两 种 实现 方式 : 


2. HttpBroadcast 
顾名思义 ，HttpBroadcast 就 是 每 个 executor 通过 的 http 协议 连接 driver 并 从 driver 那里 fetch data。 


Driver 先 准 各 好 要 broadcast 的 data， 调 用 sc.broadcast(data) 后 会 调用 工厂 方法 建立 一 个 HttpBroadcast 对 象 。 该 对 象 做 
的 第 一 件 事 就 是 将 data 存 到 driver 的 blockManager 里 面 ，StorageLevel 为 内 存 十 磁盘 ，blockld 类 型 为 
BroadcastBlockld。 


同时 driver 也 会 将 broadcast 的 data 写 到 本 地 磁盘 ， 例 如 写 入 后 得 到 
/var/folders/87/grpn1_fn4xq5wdqmxk31v06100000gp/T/spark-6233b09c-3c72-4a4d-832b-6c0791d0eb9c/broadcast_0， 这 个 文件 夹 作 


为 HttpServer 的 文件 目录 。 


Driver 和 executor 启动 的 时 候 ， 都 会 生成 broadcastManager 对 象 ， 调 用 HttpBroadcast.initialize()，driver 会 在 本 地 
建立 一 个 临时 目录 用 来 存放 broadcast 的 data， 并 启动 可 以 访问 该 目录 的 httpServer。 


Fetch data : 在 executor 反 序 列 化 task 的 时 候 ， 会 同时 反 序 列 化 task 中 的 bdata 对 象 ， 这 时 候 会 调用 bdata 的 
readObject() 方法 。 该 方法 先 去 本 地 blockManager 那里 询问 bdata 的 data 在 不 在 blockManager 里 面 ， 如 果 不 在 就 使 用 
http 协议 连接 driver 上 的 httpServer， 将 data fetch 过 来 。 得 到 data 后 ， 将 其 存放 到 blockManager 里 面 ， 这 样 后 面 运行 
的 task 如 果 需 要 bdata 就 不 需要 再 去 fetch data 了 。 如 果 在 ， 就 直接 拿 来 用 了 。 


HttpBroadcast 最 大 的 问题 就 是 driver 所 在 的 节点 可 能 会 出 现 网 络 拥 堵 ， 因 为 worker 上 的 executor 都 会 去 driver 那里 fetch 
数据 。 


3. TorrentBroadcast 


为 了 解决 HttpBroadast 中 driver 单 点 网 络 拍 颈 的 问题 ，Spark 又 设计 了 一 种 broadcast 的 方法 称 为 TorrentBroadcast， 这 个 
类 似 于 大 家 常用 的 BitTorrent 技术 。 基 本 思想 就 是 将 data 分 块 成 data blocks， 然 后 假设 有 executor fetch 到 了 一 些 data 
blocks， 那 么 这 个 executor 就 可 以 被 当 作 data server 了 ， 随 着 fetch 的 executor 越 来 越 多 ， 有 更 多 的 data server 加 入 ， 
data 就 很 快 能 传播 到 全 部 的 executor 那里 去 了 。 


HttpBroadcast 是 通过 传统 的 http 协议 和 httpServer 去 传 data， 在 TorrentBroadcast 里 面 使 用 在 上 一 章 介 绍 的 
blockManager.getRemote() => NIO ConnectionManager 传 数据 的 方法 来 传递 ， 读 取 数 据 的 过 程 与 读 取 cached rdd 的 方式 
类 似 ， 可 以 参阅 CacheAndCheckpoint 中 的 最 后 一 张 图 。 


下 面 讨论 TorrentBroadcast 的 一 些 细节 : 
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driver 量 : 


Driver 先 把 data 序列 化 到 byteArray， 然 后 切割 成 BLOCK _SIZE (由 spark.broadcast .blocksize = 4MB 设置 ) 大 小 的 data 
block， 入 data block 被 TorrentBlock 对 象 持 有 。 切割 完 byteArray 后 ， 会 将 其 回收 ， 因 此 内 存 消耗 虽然 可 以 达到 2 * 
Size(data)， 但 这 是 暂时 的 。 


完成 分 块 切割 后 ， 就 将 分 块 信息 ( 称 为 meta 信息 ) 存放 到 driver 自己 的 blockManager 里 面 ，StorageLevel 为 内 存 十 磁 
意 ， 同 时 会 通知 driver 自己 的 blockManagerMaster 说 meta 信息 已 经 存放 好 。 通 知 blockManagerMaster 这 一 步 很 重要 ， 


为 blockManagerMaster 可 以 被 driver 和 所 有 executor 访问 到 ， 信 息 被 存放 到 blockManagerMaster 束 变 成 了 全 局 信 
自 


之 后 将 每 个 分 块 data block 存放 到 driver 的 blockManager 里 面 ，StorageLevel 为 内 存 十 磁盘 。 存 放 后 仍然 通知 
blockManagerMaster 说 blocks 已 经 存放 好 。 到 这 一 步 ，driver 的 任务 已 经 完成 。 


Executor 冰 : 


executor 收 到 serialized task 后 ， 先 反 序 列 化 task， 这 时 候 会 反 序 列 化 serialized task 中 包含 的 bdata 类 型 是 
TorrentBroadcast， 也 就 是 去 调用 TorrentBroadcast.readObject()。 这 个 方法 首先 得 到 bdata 对 象 ， 然 后 发 现 bdata 里 面 没 
有 包含 实际 的 data。 怎 么 办 ? 先 询问 所 在 的 executor 里 的 blockManager 是 会 否 包含 data (通过 查询 data 的 
broadcastld) ， 包 含 就 直接 从 本 地 blockManager 读 取 data。 否 则 ， 就 通过 本 地 blockManager 去 连接 driver 的 
blockManagerMaster 获取 data 分 块 的 meta 信息 ， 获 取信 息 后 ， 就 开始 了 BT 过 程 。 


BT 过 程 : task 先 在 本 地 开 一 个 数组 用 于 存放 将 要 fetch 过 来 的 data blocks arrayofBlocks = new Array[TorrentBlock] 
(totalBlocks) ，TorrentBlock 是 对 data block 的 包装 。 然 后 打 乱 要 fetch 的 data blocks 的 顺序 ， 比 如 如 果 data block 共有 5 
个 ， 那 么 打 乱 后 的 fetch 顺序 可 能 是 3-1-2-4-5。 然 后 按照 打 乱 后 的 顺序 去 fetch 一 个 个 data block。fetch 的 过 程 就 是 通过 
“本 地 blockManager 一 本 地 connectionManager 一 driver/executor 的 connectionManager 一 driver/executor 的 
blockManager 一 data" 得 到 data， 这 个 过 程 与 fetch cached rdd 类 似 。 每 fetch 到 一 个 block 就 将 其 存放 到 executor 的 
blockManager 里 面 ， 同 时 通知 driver 上 的 blockManagerMaster 说 该 data block 多 了 一 个 存储 地 址 。 这 一 步 通知 非常 重 
要 ， 意 味 着 blockManagerMaster 知道 data block 现在 在 cluster 中 有 多 份 ， 下 一 个 不 同 节点 上 的 task 再 去 fetch 这 个 data 
block 的 时 候 ， 可 以 有 两 个 选择 了 ， 而 且 会 随机 选择 一 个 去 fetch。 这 个 过 程 持续 下 去 就 是 BT 协议 ， 随 着 下 载 的 客户 端 越 来 
越 多 ，data block 服务 器 也 越 来 越 多 ， 就 变 成 p2p 下 载 了 。 关 于 BT 协议 ，Wikipedia 上 有 一 个 动画 )。 


整个 fetch 过 程 结束 后 ，task 会 开 一 个 大 Array[Byte]， 大 小 为 data 的 总 大 小 ， 然 后 将 data block 都 copy 到 这 个 Array， 然 
后 对 Array 中 bytes 进行 反 序列 化 得 到 原始 的 data， 这 个 过 程 就 是 driver 序列 化 data 的 反 过 程 。 


最 后 将 data 存放 到 task 所 在 executor 的 blockManager 里 面 ，StorageLevel 为 内 存 十 磁盘 。 显 然 ， 这 时 候 data 在 
blockManager 里 存 了 两 份 ， 不 过 等 全 部 executor 都 fetch 结束 ， 存 储 data blocks 那 份 可 以 删 掉 了 。 
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问题 : broadcast RDD 会 怎样 3 


@Andrew-Xia 回答 道 : 不 会 怎样 ， 就 是 这 个 rdd 在 每 个 executor 中 实例 化 一 份 。 


Discussion 


公共 数据 的 broadcast 是 很 实用 的 功能 ， 在 Hadoop 中 使 用 DistributedCache， 比 如 常用 的 -1ibjars 就 是 使 用 
DistributedCache 来 将 task 依赖 的 jars 分 发 到 每 个 task 的 工作 目录 。 不 过 分 发 前 DistributedCache 要 先 将 文件 上 传 到 
HDFS。 这 种 方式 的 主要 问题 是 资源 瀛 费 ， 如 果 某 个 节点 上 要 运行 来 自 同 一 job 的 4 个 mapper， 那 么 公共 数据 会 在 该 节点 上 
存在 4 份 ( 每 个 task 的 工作 目录 会 有 一 份 ) 。 但 是 通过 HDFS 进行 broadcast 的 好 处 在 于 单 点 瓶颈 不 明显 ， 因 为 公共 data 
首先 被 分 成 多 个 block， 然 后 不 同 的 block 存放 在 不 同 的 节点 。 这 样 ， 只 要 所 有 的 task 不 是 同时 去 同一 个 节点 fetch 同一 个 
block， 网 络 拥塞 不 会 很 严重 。 


对 于 Spark 来 讲 ，broadcast 时 考虑 的 不 仅 是 如 何 将 公共 data 分 发 下 去 的 问题 ， 还 要 考虑 如 何 让 同一 节点 上 的 task 共享 
data。 


对 于 第 一 个 问题 ，Spark 设计 了 两 种 broadcast 的 方式 ， 传 统 存在 单 点 瓶颈 问题 的 HttpBroadcast， 和 类 似 BT 方式 的 
TorrentBroadcast。HttpBroadcast 使 用 传统 的 client-server 形式 的 HttpServer 来 传递 真正 的 data， 而 TorrentBroadcast 使 
用 blockManager 自 带 的 NIO 通信 方式 来 传递 data。TorrentBroadcast 存在 的 问题 是 慢 馈 动 和 占 内 存 ， 慢 启动 指 的 是 刚 开始 
data 只 在 driver 上 有 ， 要 等 executors fetch 很 多 轮 data block 后 ，data server 才 会 变 得 可 观 ， 后 面 的 fetch 速度 才 会 变 
快 。executor 所 占 内 存 的 在 fetch 完 data blocks 后 进行 反 序 列 化 时 需要 将 近 两 倍 data size 的 内 存 消耗 。 不 管 哪 一 种 方式 ， 
driver 在 分 块 时 会 有 两 倍 data size 的 内 存 消耗 。 


对 于 第 二 个 问题 ， 每 个 executor 都 包含 一 个 blockManager 用 来 管理 存放 在 executor 里 的 数据 ， 将 公共 数据 存放 在 
blockManager 中 〈StorageLevel 为 内 存 十 磁盘 ) ， 可 以 保证 在 executor 执行 的 tasks 能 够 共享 data。 


其 实 Spark 之 前 还 党 试 了 一 种 称 为 TreeBroadcast 的 机 制 ， 详 情 可 以 见 技术 报告 Performance and Scalability of Broadcast 
in Spark。 


更 深入 点 ，broadcast 可 以 用 多 播 协议 来 做 ， 不 过 多 播 使 用 UDP， 不 是 可 靠 的 ， 仍 然 需要 应 用 层 的 设计 一 些 可 靠 性 保障 机 
制 。 
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